[
Lists Home |
Date Index |
Thread Index
]
At 03:17 AM 4/2/2003 +1000, Rick Jelliffe wrote:
>One important application of XML is as source code.
>
>Imagine if a programming editor opened your Perl/Python/C#/Java/C++/SQL
>program, renamed names of modules or classes or private methods or packages,
>and threw away comments. You would undoubtedly spew, despite your
>admirably easy-going nature.
Yes, but my programming editor does not try to reconstruct the text from a
parsed form - the text is treated as input, and can be stored intact. I can
also compile modules and store a binary representation intact, and link
such modules together to build an application - the compiled form ignores
lots of stuff, and if I have to decompile, the decompiler uses a pretty
printer, since the original formatting is lost.
And that's pretty much what I do with XML most of the time. I have indeed
gotten frustrated with editors that don't care for my whitespace
adequately, and I've gone to using Emacs for most XML editing. I expect to
be able to validate from within my editor, which I can. That means I'm not
using the "compiled views" of XML - the tree view or the browser view -
from within the editor. I do use these views, but they don't change my source.
That may mean I'm an odd duck. But I don't see why the Information Set,
which says what is information and what is noise, should simply say that
everything is information because lexical round tripping is important.
Lexical round tripping is -- lexical. That's what text editors are for.
They are nicely lexical. Parsers aren't.
>Someone wrote:
>
> > >If the Information Set says that there is no distinction between <foo
> > >"a"/> and <foo 'a'/>, why should I work hard to preserve the
> > >distinction?
>
>Because syntactic sugar is vital for humans, and can help processing.
>
>This here thread comes out of a complaint about XML being too complex
>to use regexes. Yet if we canonicalize our data (say, including that only <foo
>x="a" /> is used ) then the regular expressions simplify themselves to
>something
>much more useable. If other software messes up this canonical form,
>then we have to re-canonicalize it. (Which suggests not that we should
>work hard to preserve the distinction, but that if it is convenient we should
>support it.)
Canonicalization can really reduce the distance between a lexical
representation and the parsed form, which can be helpful.
Jonathan
|
