Re: XML and Lout already work well

[franck]

Greg:

> In computing the problems are even more critical -- loss of culture
> equates to loss of knowledge of the many and varied techniques at
> problem solving.

I would argue that varied syntax contributes much less to 
problem solving than interoperability.

> If all the world wrote all their documents in XML
> using the same DTD,

Of course, few people want one 'DTD'! Varied semantic models 
contribute much more to problem solving than varied syntax.

> Lout allows you to to be pedantic about your
> syntax if you want, so what's the problem?

There's no 'problem'. Someone (sorry for misquoting Giovanni) said 
that Lout syntax was equivalent to XML. I just expressed the opinion 
that it's not because XML is more formal, so, at least if you value 
formality, XML is 'better'. This is just an opinion, which is 
balanced by the opinion that changing Lout's existing syntax is 
not useful.

>So forget lout and use XML exclusively.

I see no reason to be an extremist. You can have an ideal 
and do things that diverge slightly from the ideal. Good 
tools are more common than perfect tools, and the definition 
of perfection varies!

>To the average user the meaning of the stand-alone address@hidden' is clear and
>there's no real reason to use the more complex (and thus more error
>prone) form.

How does the average user know whether in this example

@PP Abc

@List
...
@EndList

@PP Abc def ghi.

@List/@EndList is part of the first paragraph or creates a 
new paragraph? This is not clear. In a layout where a paragraph 
is indented, and a list is also indented relative to its 
container, the two interpretation lead to different results. 
I don't think ambiguity is user friendly.

Valeriy's argument that people tolerate ambiguity and will 
interpret ambiguity in the same way most of the time is 
quite a good one. (Although I'm at a loss to guess the 
right natural interpretation of the example above.)

>> ... </p>
>Me too, though in modern HTML that practice is explicitly deprecated.

XHTML being the most modern HTML, it became mandatory.

>inelegant to use directly from the keyboard and all the redundant crud

As it's standardised, you have a choice of editors which can 
hide what you feel is redundant for you.

> So the task is to write an XML to lout compiler then, no?
...
>Why do you say a preprocessor (I think it would have to be more properly
>called a compiler though) is "of little use"?

A new preprocessor is not very useful because XSLT works very well 
for that purpose, it has a choice of implementations and is well 
documented. Lout is also at the end of the chain, so you gain 
no benefit in the possibility of further transformation you'd 
have with an XML syntax.

Actually, I thought about writing a "LoutML" myself some time 
ago. I did lose all incentive to do that after I started using 
XSLT. It works too well to be worth spending time on a Lout-specific 
preprocessor. Also, for it to be useful LoutML should also 
duplicate the doc (no point in having a LoutML if you have 
to read the standard doc and learn Lout syntax anyway). As 
Valeriy says, available resources would be better spent on 
either the Lout layout engine (or generic XML tools for 
those into XML).

Giovanni:

> Maybe, but the XML affaire is not about syntax, it's just little more 
> than a lexical maquillage.

I think we are talking about the same thing, even if we may not 
be in synch on the meaning of the word 'syntax' (I have no 
idea if my use is correct).

> I can hardly guess what a tool "whose semantics is language independent"

Structured editing, transforming from one semantic model ('DTD') 
to another, structured storage (database), search (finding subsets 
within the structure), and within a program some libraries you 
can share (parsing, etc). All of these tool need the structure 
(marked up text producing a sort of tree data model) but do not 
need to know what the structure means.

Same as a line text editor is a generic tool for a simple markup 
language with just two elements: character data and line 
separator.

-- 
Franck Arnaud ~ email: address@hidden