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

Re: JSR 206 and SAX

• To: "Norman Walsh" <ndw@n...>,<xml-dev@l...>
• Subject: Re: JSR 206 and SAX
• From: "Jeff Rafter" <lists@j...>
• Date: Fri, 20 Feb 2004 13:42:39 -0800
• References: <87znbgt3nb.fsf@n...> <40341A54.40806@a...> <87n07elu8e.fsf@n...> <p06010203bc5acccee4c1@[192.168.254.4]> <014f01c3f73a$eb5b7830$6403a8c0@ARIMATHEA> <87isi13bhr.fsf@n...>

/ "Jeff Rafter" <lists@j...> was heard to say:
| Define problem. If the feature is not supported or not recognized the
| appropriate SAXException should be raised during the call to getFeature.

> Yep.

| Unfortunately, in this proposal there is nothing per se about what to do
| when the document is or is not full normalized. Perhaps Locator2 needs

> My thinking was that if the document wasn't normalize, an error would
> be raised. If the parse finishes without raising an error, it's
> normalized.

| Additionally, I would question whether or not a feature should be provided
| for normalization transcoding or if that was beyond the scope of SAX. I

> I think that's application-level functionality that belongs in a layer
> above SAX.

I am not sure I comfortable elevating this to error status. At best, I would
think this would be a warning() because it is a purely process oriented
problem-- i.e., you simply can't do a byte for byte unicode comparisson-- 
this isn't an error, you should simply be warned about the inability to
perform the test.

Secondly, this is something which in a non-normalized document will possibly
occur a lot. This would create a lot of noise in an error listing-- and
likewise for a listing of errors+warnings in the document as many editors
do. Additionally, the repetition of the non-normalized warning/error means
creating a new SAXParseException *every* time. This goes back to a
conversation Karl Waclawek and I have been having off list about the
performance penalties involved in the current design-- but that is probably
a discussion for another time...

I think we need to have a defined scenario/use case for how the information
will actually be used before it is finalized. e.g., when such a
warning/error would occur, what an ideal line number and column position
would be, what the order of events would be when the processor encountered
such a warning. Should the warning be fired for every instance of
non-full-normalization? If not, what is the benefit to using the
ErrorHandler at all instead of a single check for isFullyNormalized? When
multiple errors/warnings occur (e.g. one for each occurence of
non-full-normalization, there is great ambiguity:

e.g. This is somewhat clear:

  [startElement]
  [startElement]
  [warning non-nomalized text]
  [characters]

while this is not:

  [warning non-nomalized text]
  [startElement]

When the element name is non-nomalized? When the attribute name is non
normalized? When the attribute content is non-normalized?

What about:

  [warning non-nomalized text]
  [startPrefixMapping]
  [startElement]

Again, it is difficult to determine where exactly the warning should be
applied. Does it matter?

Best Regards,
Jeff Rafter

• References:
  • JSR 206 and SAX
    • From: Norman Walsh <ndw@n...>
  • Re: JSR 206 and SAX
    • From: David Megginson <dmeggin@a...>
  • Re: JSR 206 and SAX
    • From: Norman Walsh <ndw@n...>
  • Re: JSR 206 and SAX
    • From: Elliotte Rusty Harold <elharo@m...>
  • Re: JSR 206 and SAX
    • From: "Jeff Rafter" <lists@j...>
  • Re: JSR 206 and SAX
    • From: Norman Walsh <ndw@n...>

• Prev by Date: RE: RDDL: Can we add a "copyright" version
• Next by Date: Re: Local Vs Global Vocabularies
• Previous by thread: Re: JSR 206 and SAX
• Next by thread: SAX and XML Version (was Re: JSR 206 and SAX)
• Index(es):
  • Date
  • Thread