• From: David Brownell <david-b@p...>
• To: Rob Lugt <roblugt@e...>
• Date: Tue, 20 Feb 2001 16:28:07 -0800

I'm not sure what those "several places" are that you're referring to;
no, not convinced.  Not that it matters much ... there are ways
that specs write "here be dragons".  By using curious phrases
like "XML Processor", and vague compliance levels like "error",
that's exactly what the spec did.  Red Dragon -- or Blue?  Either
way, safety calls for the app to be careful.

- Dave


> But what exactly consitutes an XML Processor?  I would say that the SAX API
> allows the application to intervene in several places that (according to the
> XML 1.0 recommendation) are the responsibility of the XML processor.  So, in
> this case, by deciding to pass the SAX Parser a character stream, the
> application has taken on part of the responsibility of an XML processor -
> namely the responsibility of dealing with any encoding issues, thereby
> relieving the SAX processor of any need, indeed any right, to have an
> opinion on how the encoding is performed.
> 
> Still not convinced?
> 
> Regards
> Rob Lugt
> ElCel Technology
> 
> 

• References:
  • SAX InputSource and character streams
    • From: Mike Brown <mike@s...>
  • Re: SAX InputSource and character streams
    • From: Rob Lugt <roblugt@e...>
  • Re: SAX InputSource and character streams
    • From: David Brownell <david-b@p...>
  • Re: SAX InputSource and character streams
    • From: Rob Lugt <roblugt@e...>

• Prev by Date: Re: SAX InputSource and character streams
• Next by Date: Re: Passing thru html to the browser
• Previous by thread: Re: SAX InputSource and character streams
• Next by thread: Re: SAX InputSource and character streams
• Index(es):
  • Date
  • Thread