Cart
|
[XML-DEV Mailing List Archive Home] [By Thread] [By Date] [Recent Entries] [Reply To This Message] Re: JSR 206 and SAX
/ David Megginson <dmeggin@a...> was heard to say:
[...]
| I sympathize with the fact that the JSR 206 deadline is pressing, but
| let's shift the focus to SAX itself, since many of us (including me)
| have never looked at Sun's Java XML APIs. Perhaps Norm could post a
| short list of changes that he believes are necessary for SAX2 to
| support XML 1.1 and Namespaces 1.1 properly. We can discuss them for
| a few days, and then consider some code and documentation changes for
| SAX itself.
The short thread that followed my initial posting has already proved
valuable and productive. I extend thanks to Jeff, Elliotte, David, and
others who helped clarify my understanding of a few points.
At the JSR 206 Expert Group (EG) call today, we discussed the issues
in light of the discussion here and found that a very short list of
changes would seem to be sufficient to meet our needs. I don't
anticipate that any of them will be deeply controversial, though one
or two are substantive, so I am now cautiously optimistic that
everything will work out.
- The consensus seems to be that the we can in fact support XML 1.1
and Namespaces 1.1 through the extension framework. The process
hurdle of making that a "real" distribution instead of an "alpha"
distribution remains, but hopefully that's not a problem.
- The CVS sources for Attributes.java includes this paragraph of
JavaDoc that is not in the 2.0.1 release:
* <p>Some SAX2 parsers may support using an optional feature flag
* (<code>http://xml.org/sax/features/xmlns-uris</code>) to request that
* those attributes be given URIs, conforming to a later
* backwards-incompatible revision of that recommendation.
* (The attribute's "local name" will be the prefix, or the empty
* string when defining a default element namespace.)
* For portability, handler code should always resolve that conflict,
* rather than requiring parsers that can change the setting of that
* feature flag.
* </p>
We'd like to see that text in a "real" distribution of the API.
The interaction between the http://xml.org/sax/features/xmlns-uris
feature and the http://xml.org/sax/features/namespace-prefixes
feature needs to be clearly spelled out. If adding the above text to
a release is acceptable, I volunteer to propose some additional JavaDoc
to clarify how it interacts with namespace-prefixes.
- Michael's message raised an issue that we had, as far as I can tell,
simply failed to consider: Unicode normalization checking. The XML
1.1 spec says "XML processors SHOULD provide a user option to verify
that the document being processed is in fully normalized form". We
propose that a feature be added to the XMLReaderFactory, perhaps
http://xml.org/sax/features/unicode-normalization-checking. If this
feature is enabled, the factory returns readers that perform Unicode
normalization checking. The EG felt that this feature was most
appropriate at the factory level.
- There are a number of documentation bug fixes throughout the API,
mostly specific references to "XML 1.0" where it would be more
appropriate today to simply refer to "XML" or "XML 1.0 and XML 1.1"
that we'd like to see fixed. I've already taken a pass through the
JavaDoc and fixed these. I'd be happy to provide a patch for general
inspection, if the community is willing in spirit to make these
changes.
Thanks again, for your help and I hope that these proposals will
inspire productive discussion.
Be seeing you,
norm
--
Norman Walsh <ndw@n...> | To the man who is afraid everything
http://nwalsh.com/ | rustles.-- Sophocles
|
PURCHASE STYLUS STUDIO ONLINE TODAY!Purchasing Stylus Studio from our online shop is Easy, Secure and Value Priced! 
Download The World's Best XML IDE!Accelerate XML development with our award-winning XML IDE - Download a free trial today! Subscribe in XML format
|
|||||||||
