[XML-DEV Mailing List Archive Home] [By Thread] [By Date] [Recent Entries] [Reply To This Message]

RE: SAX-ext Attribute + Entity Parsing

  • From: "Bullard, Claude L (Len)" <clbullar@i...>
  • To: Tim Shaw <tim@e...>
  • Date: Wed, 28 Feb 2001 09:51:05 -0600

sax expand entity
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@e...]
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.

PURCHASE STYLUS STUDIO ONLINE TODAY!

Purchasing Stylus Studio from our online shop is Easy, Secure and Value Priced!

Buy Stylus Studio Now

Download The World's Best XML IDE!

Accelerate XML development with our award-winning XML IDE - Download a free trial today!

Don't miss another message! Subscribe to this list today.
Email
First Name
Last Name
Company
Subscribe in XML format
RSS 2.0
Atom 0.3
 

Stylus Studio has published XML-DEV in RSS and ATOM formats, enabling users to easily subcribe to the list from their preferred news reader application.


Stylus Studio Sponsored Links are added links designed to provide related and additional information to the visitors of this website. they were not included by the author in the initial post. To view the content without the Sponsor Links please click here.

Site Map | Privacy Policy | Terms of Use | Trademarks
Free Stylus Studio XML Training:
W3C Member
Stylus Studio® and DataDirect XQuery ™are products from DataDirect Technologies, is a registered trademark of Progress Software Corporation, in the U.S. and other countries. © 2004-2013 All Rights Reserved.