[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
RE: SAX-ext Attribute + Entity Parsing
- From: "Bullard, Claude L (Len)" <firstname.lastname@example.org>
- To: Tim Shaw <email@example.com>
- Date: Wed, 28 Feb 2001 09:51:05 -0600
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?
Ekam sat.h, Vipraah bahudhaa vadanti.
Daamyata. Datta. Dayadhvam.h
From: Tim Shaw [mailto:firstname.lastname@example.org]
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
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