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

Re: SAX-ext Attribute + Entity Parsing

• From: Tim Shaw <tim@e...>
• To: "Bullard, Claude L (Len)" <clbullar@i...>
• Date: Wed, 28 Feb 2001 16:50:47 +0000

Len's right, of course. 4.4.3 of the XML-Rec forces the parser to
include the replacement text.
Interestingly tho' (to me anyway) is that it allows the parser to *not*
replace the text if the Entity is External and the parser's not
validating. The reason given is :
"This rule is based on the recognition that the automatic inclusion
provided by the SGML and XML entity mechanism, primarily designed to
support modularity in authoring, is not necessarily appropriate for
other applications, in particular document browsing."

I think my problem is that I'm trying to do something that wasn't
catered for - process the meta-info at its lowest level ... and I'd like
to be able to store and restore (and edit) the internal entities. Shame
this exclusion clause doesn't apply ... obviously my sort of tool wasn't
envisaged ;-)

My apologies for implying that SAX was at 'fault' ... although I still
think a property would be a good solution to my problem without
impacting current applications in any way. I take the point about the
'other end of the wire' - but I am the other end of the wire in this
case ... I'd be happy to have an extra callback 'unparsedElementDecl'
which could be could be inserted as a separate handler via the property
...

I don't hold out much hope for a change to the XML REC (!=Spec) or any
parsers, so I'll just have to do a 'special' - and move away from my
goal of standards compliance ...

Thanks

tim


"Bullard, Claude L (Len)" wrote:
> 
<snip>
> 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.

• References:
  • RE: SAX-ext Attribute + Entity Parsing
    • From: "Bullard, Claude L (Len)" <clbullar@i...>

• Prev by Date: <xinclude> & unimplementable specs
• Next by Date: test
• Previous by thread: RE: SAX-ext Attribute + Entity Parsing
• Next by thread: <xinclude> & unimplementable specs
• Index(es):
  • Date
  • Thread