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 ]

/ David Megginson <dmeggin@attglobal.net> 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

Thanks again, for your help and I hope that these proposals will
inspire productive discussion.

                                        Be seeing you,

Norman Walsh <ndw@nwalsh.com> | To the man who is afraid everything
http://nwalsh.com/            | rustles.-- Sophocles


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

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