OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.


Help: OASIS Mailing Lists Help | MarkMail Help



   Re: [xml-dev] JSR 206 and SAX

[ Lists Home | Date Index | Thread Index ]

/ "Jeff Rafter" <lists@jeffrafter.com> 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:

  [warning non-nomalized text]

while this is not:

  [warning non-nomalized text]

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]

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

Best Regards,
Jeff Rafter


News | XML in Industry | Calendar | XML Registry
Marketplace | Resources | MyXML.org | Sponsors | Privacy Statement

Copyright 2001 XML.org. This site is hosted by OASIS