OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.


Help: OASIS Mailing Lists Help | MarkMail Help



   Re: [xml-dev] Simplify XML Now? (Was RE: [xml-dev] Re: Hostility to "bi

[ 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" 
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.

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.


News | XML in Industry | Calendar | XML Registry
Marketplace | Resources | MyXML.org | Sponsors | Privacy Statement

Copyright 2001 XML.org. This site is hosted by OASIS