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

 


Help: OASIS Mailing Lists Help | MarkMail Help

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

RE: SAX-ext Attribute + Entity Parsing



I think they will switch eventually.  It makes 
too much sense to have declarations and processors that are 
type-aware beyond a string.  A lot of the hideousness 
of X3D design came about in the confusion of 
designing a DTD on one hand but trying to match 
the VRML abstract data model on the other 
(the designers were learning XML and DTD design 
while the targets were moving).  

In VRML97, the instance and the abstract data model 
are defined in the same model. VRML97 is a boxed-app.
Not a meta-design by any stretch.  When some 
appealed to the XML infoSet, it was first not understood 
to be important by some, and second, proved inadequate 
for others (the node/field mismatch).  It was clearly 
a case where grove design would have outed the 
inconsistencies. But that is a different issue...

Perhaps the role of SAX in the pipeline should 
be explored.  In other works, precisely why 
does it expand the entity now?  I thought that 
was an XML rule, not a SAX rule.   I am leery of 
parser switches because as the first level of 
"handling", I prefer the parser to act exactly the same 
wherever it acts and not have options that 
make the data handling at the other end of the 
wire unpredictable.  Well-formed should mean 
well-formed, not formed-according-to-switch.

In other words, would that switch lessen or 
improve interoperability or have no impact?

Len
http://www.mp3.com/LenBullard

Ekam sat.h, Vipraah bahudhaa vadanti.
Daamyata. Datta. Dayadhvam.h


-----Original Message-----
From: Tim Shaw [mailto:tim@everserve.co.uk]
Sent: Wednesday, February 28, 2001 9:26 AM
To: Bullard, Claude L (Len)
Cc: Justin Couch; XML-Dev
Subject: Re: SAX-ext Attribute + Entity Parsing


... but I've got the same problem trying to support an XML repository of
'legacy' DTD files (and I'm not convinced everyone is going to switch to
XML Schema). The information is there, but inaccessible at the SAX2
level.

Would it not make sense to allow people like myself (and Justin) access
to slightly lower-level info by adding a property to SAX2 which says "do
not expand internal entities, but leave them in place"? (thanks Justin)

Given that an internal entity is a reported Infoset declaration, I would
suggest that allowing the 'user' to switch on/off the parser's 'hiding'
of the use of the item is a reasonable request.

There are lotsa re-usable internal entities out there, and I'd like to
be able to capture the original (well-informed and thought out)
intention of the authors. Hopefully this will help them retain their
re-usability when (if) they use tools like ours to migrate to XML
Schema.