[
Lists Home |
Date Index |
Thread Index
]
----- Original Message -----
From: "Bullard, Claude L (Len)" <len.bullard@intergraph.com>
To: "'Oleg Tkachenko'" <oleg@tkachenko.com>; "Michael Champion"
<michaelc.champion@gmail.com>
Cc: "Robin Berjon" <robin.berjon@expway.fr>; <xml-dev@lists.xml.org>
Sent: Tuesday, November 23, 2004 8:14 AM
Subject: [xml-dev] Simplify XML Now? (Was RE: [xml-dev] Re: Hostility to
"binary XML" (was Re: [xml-dev] XML 2004 weblog items?))
> Norm makes good points. Derek has made good points in his blogs.
> That is what makes me think the time has come to consider this.
> There is sufficient shared experience to do it just as there
> was when it was done to SGML.
>
> It seems that is what experience teaches in every creative
> endeavour: what to leave out.
>
I had read it, and think this seems like a good approach.
ammusingly enough, a lot of things I had failed to implement in my parser
were those things he had mentioned to leave out, largely for the reason that
they had not seemed to pop up in the kinds of data I was dealing with.
for other things, I am less sure, but here goes.
I feel a little unsure of merging in qnames, and his proposed syntax was
just ugly. others were proposing overloading '&'. at least this looks better
imo, but seems to solve one issue with another.
I think someone else suggested using '%'.
imo I would be ok with '%' and not actally changing things at the parser
level (processing of them would still be left to layers above the parser). I
will draw an analogy, eg, with c's printf syntax. printf's syntax isn't part
of the core language, but at the same time makes things more flexible.
people, however, realize in many cases to be careful with '%', as probably
those dealing with a modified syntax would.
probably %% could be used as an escaped form of %.
ok, so my whole oppinion I guess boils down to:
rip out doctypes, dtd's, custom entities, ...
make use of namespaces at the toplevel (this is actually an approach I have
used personally).
maybe dtd's could be replaced, eg, by a variant using a more normal syntax,
or just ommited.
&:prefix:name;
imo, could make sense for a kind of entity.
entities could be namespace qualified like everything else, and if the app
doesn't recognize a character's namespace, it is sol, and will have to deal
with it somehow (the box character comes to mind).
ok, so the parser sees this, and possibly resolves the mark to some specific
character (eg: internally parts of the character space could be defined
dynamically), and inserts that character in place of the original mark, or
failing that, inserts some default.
I would personally just rather stick with the predefined ones. custom
entities are probably necessary somehow, oh well.
|
