Hi all, Elena and I were just looking over the proposed final draft of JSR 173, which is apparently up for final approval ballot voting in little more than a week. A few things jumped out rather forcefully at us, and we were wondering whether anyone else had had similar reactions. Firstly, although we can--with some creativity--imagine applications that would use the event portion of the spec, it seems that there is a very natural layering which the spec does not exploit. That is, the much more broadly-applicable streaming portion does not depend on the events portion in any logical way, but is inextricably intermingled with it. It seems to me that this is tantamount to making DOM level 3 Core depend on DOM events, or having the base SAX interfaces depend on the SAX extensions. We are concerned that fewer people might want to implement this spec because of this dependence on events than would otherwise be the case if there were a basic "core" supporting streaming, and a module describing the events that was optional and separate. It also seems to us that the overall quality of the spec seems somewhat dubious. It's easy to find examples where methods are underspecified, javadocs not well-written, and areas that don't appear to have gained from the lessons learned by other XML parsing API's. Some examples are: * Resetting: It is not possible to reset XMLStreamReader. For performance reasons, an application should be allowed to reset the reader instead of being required to create a new reader on each parse. * javax.xml.stream.isCoalescing: This feature should be optional -- not every implementation will want to support it for performance reasons. In addition, this kind of a feature might expose new security holes in implementations. * EntityResolver: SAX, DOM L3, XNI entity resolvers specify that publicId can be passed to the application. However STAX chooses only to pass uri, and it is not clear how would it be possible to resolve DTD external entities referenced by publicId or to support XML Catalogs. It is unclear how XML Schemas resolution could be supported by this API. * Surprisingly, there is no way to skip element children. This requirement has been known for a long time and it feels odd that this is not part of the API. * Validation: while other specifications like JAXP specify the schema type against which validation should occur, STAX fails to specify what should happen when isValidating (XMLInputFactory) is set to true. * Character events: the spec fails to clarify at what point character events should be reported -- is it when a parser points the character data or when the parser has already read the character data? If the former, then it is not clear how isWhitespace method can work given that parser will have to read characters to determine if those are white spaces. If later, then it is not clear why the spec has "int getTextCharacters(...)" since it seems like this method does not add any functionality but forces a parser to copy the characters into user specified array. * isWhitespace: spec fails to specify if what is "white space" is so-called "ignorable whitespace" or XML 1.0/1.1 white space. * getText* methods: The table ?Valid methods for each state? states that getText* methods are valid for the CHARACTERS, CDATA, SPACE, COMMENT events. However, descriptions for text methods are inconsistent -- sometimes descriptions only mention a subset of events which makes someone wonder which part of the specification has a typo. At other times, the description doesn't mention any events at all. * Namespaces: the Java docs stay silent on what happen when namespaces are turned off. It's obvious there's a lot of use-cases for a pull-parsing API; we are just curious to see whether anyone else out there is of the view that what's currently being proposed here might not be well-structured or mature enough to meet the need... Cheers, Neil, Elena Neil Graham XML Parser Development IBM Toronto Lab Phone: 905-413-3519, T/L 969-3519 E-mail: [EMAIL PROTECTED] --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
