[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: XML and Lout already work well
From: |
franck |
Subject: |
Re: XML and Lout already work well |
Date: |
Thu, 20 Sep 2001 13:52:10 +0100 |
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