Re: namespace-prefixes
Elliotte Rusty Harold wrote: At 9:07 PM -0800 3/4/04, Clay Leeds wrote: - if XMLReaderFactory works under JDK 1.3 and/or 1.2, what kinds of benefits might fop-0.20.5 see from a switch to XMLReaderFactory? Cleaner simpler code that's less likely to get hosed by different implementations interpreting a spec in very different ways. Plus you'll be ready for the eventual deprecation of SAXParserFactory in JAXP 1.4. And you'll be able to work with SAX parsers that don't support JAXP. Not sure how much of an issue that is any more in practice, but it was a very real issue in the recent past. It took me a little while, but I now remember again why I did not want to use the XMLReaderFactory. I do not understand how I can guarantee that I get an XMLReader that is capable of validation. In SAXParserFactory I can configure the factory to look for a validating and namespace-aware parser. In XMLReaderFactory, it may produce an XMLReader which throws an exception when I want to set the validating feature on it. Regards, Simon Pepping -- Simon Pepping home page: http://www.leverkruid.nl
Re: namespace-prefixes
At 8:53 PM +0100 3/5/04, Simon Pepping wrote: It took me a little while, but I now remember again why I did not want to use the XMLReaderFactory. I do not understand how I can guarantee that I get an XMLReader that is capable of validation. In SAXParserFactory I can configure the factory to look for a validating and namespace-aware parser. In XMLReaderFactory, it may produce an XMLReader which throws an exception when I want to set the validating feature on it. This is a new one for me, and I can see how you might think SAXParserFactory guarantees validation by looking at the API docs, but it isn't true. SAXParserFactory can indeed give you a parser that does not support validation. If you ask for validation, and a validating parser isn't available, then you'll get an exception, just as you would if you tried to set validation on an XMLReader returned by XMLReaderFactory that did not support validation. Most SAXParserFactory users have installed implementations that default to Crimson, Oracle, or Xerces, all of which validate, so they never notice this. The only way to be sure to get validation is to request a known validating parser such as Xerces by name, and it's much easier to request a known parser with XMLReaderFactory than with SAXParserFactory. The latter requires you to muck with system properties and the services API, and never be to sure whether the user is going to throw some other jar file in the mix that overrides your carefully constructed code. I remain amazed at what developers believe about SAXParserFactory that just isn't true, and what magical properties they attribute to it. I really am curious to know how these ideas took hold in the community. Possibly there was a crucial book or tutorial at some point that promulgated these mistaken ideas that I just haven't read. You know, now that I think about it that way I have a funny feeling I may know which book that was, but I'll have to wait till I get to my office on Tuesday to check. -- Elliotte Rusty Harold [EMAIL PROTECTED] Effective XML (Addison-Wesley, 2003) http://www.cafeconleche.org/books/effectivexml http://www.amazon.com/exec/obidos/ISBN%3D0321150406/ref%3Dnosim/cafeaulaitA
Re: namespace-prefixes
By the way, if you're curious you can look at the code for SAXParserFactory (and its default concrete subclass in Java 1.4) in the Apache Crimson CVS (which is ungodly slow today, not sure why). It's easy to see that it never returns any parser other than Crimson, regardless of what features you ask for. Of course, other implementations like Xerces will return different defaults. But the SAXParserFactory will not iterate through all installed parsers looking for one that satisfies all the requested features. I suppose you can imagine one that does that, but I've never seen one like that, and the one in Java 1.4 certainly doesn't do that. What's really strange though is that when you try to set a feature on the factory, then the factory actually creates an XMLReader to see if an exception is thrown, and then throws the reader away! In other words. SAXParserFactory.setFeature() invokes XMLReader.setFeature()! The SAXParserFactory doesn't even know what features it can support until the XMLReader tells it! Talk about a hack. Check it out for yourself: http://cvs.apache.org/viewcvs.cgi/xml-crimson/src/org/apache/crimson/jaxp/ -- Elliotte Rusty Harold [EMAIL PROTECTED] Effective XML (Addison-Wesley, 2003) http://www.cafeconleche.org/books/effectivexml http://www.amazon.com/exec/obidos/ISBN%3D0321150406/ref%3Dnosim/cafeaulaitA
Re: namespace-prefixes
Glen Mazza wrote: --- Peter B. West [EMAIL PROTECTED] wrote: ... That is, I would turn allow the namespace-prefixes feature to remain in its default 'false' state, but make sure the parser is namespace aware. I don't know that there is any reason for us to collect prefixes, This is somewhat outside my knowledge, but one difference, I believe, between HEAD and Alt-Design is the former's ability to have user-configured, run-time add-in element mappings. (I think we have one for MathML and another one for something else in our examples.) Given that, could that be HEAD's reason for needing to collect prefixes? I don't think so. Prefixes are a shorthand convenience - they must be supported by underlying full namespaces. Prefixes are unstable, in that the same3 prefix can signify completely different namespaces at different points in the file, IIUC. Peter -- Peter B. West http://www.powerup.com.au/~pbwest/resume.html
Re: namespace-prefixes
At 12:56 PM +1000 3/4/04, Peter B. West wrote:
Fops,
In HEAD, ///apps/FOFileHAndler.java contains the following:
protected static XMLReader createParser() throws FOPException {
try {
SAXParserFactory factory = SAXParserFactory.newInstance();
factory.setNamespaceAware(true);
factory.setFeature(
http://xml.org/sax/features/namespace-prefixes;, true);
return factory.newSAXParser().getXMLReader();
} catch (SAXNotSupportedException se) {
throw new FOPException(Error: You need a parser which allows the
+ http://xml.org/sax/features/namespace-prefixes;
+ feature to be set to true to support namespaces, se);
I would be inclined to modify that to:
protected static XMLReader createParser() throws FOPException {
try {
SAXParserFactory factory = SAXParserFactory.newInstance();
factory.setNamespaceAware(true);
return factory.newSAXParser().getXMLReader();
} catch (SAXNotSupportedException se) {
throw new FOPException(Error: You need a parser which allows the
+ http://xml.org/sax/features/namespaces;
+ feature to be set to true to support namespaces, se);
What I ask on reading this code is why you're using SAXParserFactory
at all? SAXParserFactory is a Sun class they invented to fill a hole
in SAX 1.0. It's unnecessary in SAX 2.0. SAX2 apps should use
XMLReaderFactory instead, which has the correct defaults you want in
the first place. It would look something like this:
protected static XMLReader createParser() throws FOPException {
try {
XMLReader parser = XMLReaderFactory.createXMLReader();
return parser;
} catch (SAXException se) {
throw new FOPException(Could not find a parser. Make sure the
+ system property is set);
}
}
That's off the top of my head so it may not compile, and there are
ways to look for alternative parsers if you don't find one
immediately (See
http://www.cafeconleche.org/books/xmljava/chapters/ch07.html#d0e9994
) but you get the idea.
--
Elliotte Rusty Harold
[EMAIL PROTECTED]
Effective XML (Addison-Wesley, 2003)
http://www.cafeconleche.org/books/effectivexml
http://www.amazon.com/exec/obidos/ISBN%3D0321150406/ref%3Dnosim/cafeaulaitA
Re: namespace-prefixes
--- Elliotte Rusty Harold [EMAIL PROTECTED] wrote: What I ask on reading this code is why you're using SAXParserFactory at all? SAXParserFactory is a Sun class they invented to fill a hole in SAX 1.0. It's unnecessary in SAX 2.0. SAX2 apps should use XMLReaderFactory instead, which has the correct defaults you want in the first place. It would look something like this: Mr. Harold, Pardon my ignorance here--but do the Xalan libraries that ship with the 1.4 JDK handle SAX 2.0? The Xalan home page [1] is ambiguous on their support of it, and I'm concerned if there would be compatability problems if we were to use it. Thanks, Glen [1] http://xml.apache.org/xalan-j/index.html
Re: namespace-prefixes
At 2:36 PM -0800 3/4/04, Glen Mazza wrote: --- Elliotte Rusty Harold [EMAIL PROTECTED] wrote: What I ask on reading this code is why you're using SAXParserFactory at all? SAXParserFactory is a Sun class they invented to fill a hole in SAX 1.0. It's unnecessary in SAX 2.0. SAX2 apps should use XMLReaderFactory instead, which has the correct defaults you want in the first place. It would look something like this: Mr. Harold, Pardon my ignorance here--but do the Xalan libraries that ship with the 1.4 JDK handle SAX 2.0? Yes, they absolutely do. If you're using namespaces, XMLReader, ContentHandler, and so forth (and you really have to be for XSL) then you are already using SAX 2. The Xalan home page [1] is ambiguous on their support of it, and I'm concerned if there would be compatability problems if we were to use it. I'm not quite sure what you're seeing on that page that concerns you, but I don't see anything there that should prevent you from using XMLReaderFactory. -- Elliotte Rusty Harold [EMAIL PROTECTED] Effective XML (Addison-Wesley, 2003) http://www.cafeconleche.org/books/effectivexml http://www.amazon.com/exec/obidos/ISBN%3D0321150406/ref%3Dnosim/cafeaulaitA
Re: namespace-prefixes
Elliotte Rusty Harold wrote:
At 12:56 PM +1000 3/4/04, Peter B. West wrote:
...
SAXParserFactory factory = SAXParserFactory.newInstance();
factory.setNamespaceAware(true);
return factory.newSAXParser().getXMLReader();
...
What I ask on reading this code is why you're using SAXParserFactory at
all? SAXParserFactory is a Sun class they invented to fill a hole in SAX
1.0. It's unnecessary in SAX 2.0. SAX2 apps should use XMLReaderFactory
instead, which has the correct defaults you want in the first place. It
would look something like this:
protected static XMLReader createParser() throws FOPException {
try {
XMLReader parser = XMLReaderFactory.createXMLReader();
return parser;
} catch (SAXException se) {
throw new FOPException(Could not find a parser. Make sure the
+ system property is set);
}
}
That's off the top of my head so it may not compile, and there are ways
to look for alternative parsers if you don't find one immediately (See
http://www.cafeconleche.org/books/xmljava/chapters/ch07.html#d0e9994 )
but you get the idea.
Elliotte,
I think this might be because the HEAD developers were moving to a JAXP
implementation, and SAXParserFactory is still in the 1.4
javax.xml.parsers package, which, AIUI, is what one is supposed to use
for JAXP-compatible applications. I don't know much about JAXP, so this
could be wrong.
Peter
--
Peter B. West http://www.powerup.com.au/~pbwest/resume.html
Re: namespace-prefixes
At 10:43 AM +1000 3/5/04, Peter B. West wrote: I think this might be because the HEAD developers were moving to a JAXP implementation, and SAXParserFactory is still in the 1.4 javax.xml.parsers package, which, AIUI, is what one is supposed to use for JAXP-compatible applications. I don't know much about JAXP, so this could be wrong. It's a common misconception, but it is very much a misconception. I don't know how this meme got started, but it is annoyingly persistent; and it causes people all sorts of trouble. SAXParserFactory should not be used in 2004. It does not replace XMLReaderFactory. In fact, the opposite is true. XMLReaderFactory replaces SAXParserFactory. The only reason SAXParserFactory exists is to support SAX 1.0. It is underspecified and has completely wrong defaults for handling namespaces or SAX 2. Honestly Sun should never have released it in the first place. By the time they released JAXP 1.0, SAX 2.0 was in late beta, just weeks from release, and was obviously going to render JAXP 1.0 obsolete; but Sun went ahead anyway, and thoroughly confused the market. Not invented here syndrome, I think. They simply were not willing to accept a process they didn't control. Four years later the rest of us are still paying the price for their hubris. :-( -- Elliotte Rusty Harold [EMAIL PROTECTED] Effective XML (Addison-Wesley, 2003) http://www.cafeconleche.org/books/effectivexml http://www.amazon.com/exec/obidos/ISBN%3D0321150406/ref%3Dnosim/cafeaulaitA
Re: namespace-prefixes
On Mar 4, 2004, at 6:53 PM, Elliotte Rusty Harold wrote: At 10:43 AM +1000 3/5/04, Peter B. West wrote: I think this might be because the HEAD developers were moving to a JAXP implementation, and SAXParserFactory is still in the 1.4 javax.xml.parsers package, which, AIUI, is what one is supposed to use for JAXP-compatible applications. I don't know much about JAXP, so this could be wrong. It's a common misconception, but it is very much a misconception. I don't know how this meme got started, but it is annoyingly persistent; and it causes people all sorts of trouble. SAXParserFactory should not be used in 2004. It does not replace XMLReaderFactory. In fact, the opposite is true. XMLReaderFactory replaces SAXParserFactory. The only reason SAXParserFactory exists is to support SAX 1.0. It is underspecified and has completely wrong defaults for handling namespaces or SAX 2. Honestly Sun should never have released it in the first place. By the time they released JAXP 1.0, SAX 2.0 was in late beta, just weeks from release, and was obviously going to render JAXP 1.0 obsolete; but Sun went ahead anyway, and thoroughly confused the market. Not invented here syndrome, I think. They simply were not willing to accept a process they didn't control. Four years later the rest of us are still paying the price for their hubris. :-( -- Elliotte Rusty Harold Two questions regarding this (forgive my naivete!): - does a switch from SAXParserFactory to XMLReaderFactory have any bearing on the discussion about whether FOP should change its minimum JRE from 1.3/1.2 to 1.4? - if XMLReaderFactory works under JDK 1.3 and/or 1.2, what kinds of benefits might fop-0.20.5 see from a switch to XMLReaderFactory?
Re: namespace-prefixes
On Mar 4, 2004, at 6:53 PM, Elliotte Rusty Harold wrote: At 10:43 AM +1000 3/5/04, Peter B. West wrote: I think this might be because the HEAD developers were moving to a JAXP implementation, and SAXParserFactory is still in the 1.4 javax.xml.parsers package, which, AIUI, is what one is supposed to use for JAXP-compatible applications. I don't know much about JAXP, so this could be wrong. It's a common misconception, but it is very much a misconception. I don't know how this meme got started, but it is annoyingly persistent; and it causes people all sorts of trouble. SAXParserFactory should not be used in 2004. It does not replace XMLReaderFactory. In fact, the opposite is true. XMLReaderFactory replaces SAXParserFactory. The only reason SAXParserFactory exists is to support SAX 1.0. It is underspecified and has completely wrong defaults for handling namespaces or SAX 2. Honestly Sun should never have released it in the first place. By the time they released JAXP 1.0, SAX 2.0 was in late beta, just weeks from release, and was obviously going to render JAXP 1.0 obsolete; but Sun went ahead anyway, and thoroughly confused the market. Not invented here syndrome, I think. They simply were not willing to accept a process they didn't control. Four years later the rest of us are still paying the price for their hubris. :-( -- Elliotte Rusty Harold Two questions regarding this (forgive my naivete!): - does a switch from SAXParserFactory to XMLReaderFactory have any bearing on the discussion about whether FOP should change its minimum JRE from 1.3/1.2 to 1.4? - if XMLReaderFactory works under JDK 1.3 and/or 1.2, what kinds of benefits might fop-0.20.5 see from a switch to XMLReaderFactory? Web Maestro Clay -- Clay Leeds - [EMAIL PROTECTED] Web Developer - Medata, Inc. - http://www.medata.com/ PGP Public Key: https://mail.medata.com/pgp/cleeds.asc
Re: namespace-prefixes
--- Peter B. West [EMAIL PROTECTED] wrote: In HEAD, ///apps/FOFileHAndler.java contains the following: factory.setFeature( http://xml.org/sax/features/namespace-prefixes;, true); snip/ That is, I would turn allow the namespace-prefixes feature to remain in its default 'false' state, but make sure the parser is namespace aware. I don't know that there is any reason for us to collect prefixes, This is somewhat outside my knowledge, but one difference, I believe, between HEAD and Alt-Design is the former's ability to have user-configured, run-time add-in element mappings. (I think we have one for MathML and another one for something else in our examples.) Given that, could that be HEAD's reason for needing to collect prefixes? Glen
RE: NameSpace??
I had this problem when I had old IBM's parser.jar hanging around in the classpath. Even putting xerces.jar in front didn't help, I had to explicitely set up the parser factory: System.setProperty( javax.xml.parsers.SAXParserFactory, org.apache.xerces.jaxp.SAXParserFactoryImpl ); However, your problem may be completely unrelated. YS -Original Message- From: Gerard van Wijk [mailto:[EMAIL PROTECTED]] Sent: Tuesday, October 30, 2001 5:41 AM To: '[EMAIL PROTECTED]' Subject: NameSpace?? Hello, ClassLoader loader = this.getClass().getClassLoader(); URL url = loader.getResource(cv.xsl); System.out.println(url); TransformerFactory tFactory = TransformerFactory.newInstance(); Transformer transformer = tFactory.newTransformer(new StreamSource(new File(url.getFile(; [2001/10/30 11:35:02][1 ][I]: ** Transformer Factory error [2001/10/30 11:35:02][1 ][I]: javax.xml.transform.TransformerConfigurationException: javax.xml.transform.TransformerException: Namespace not supported by SAXParser Does anyone know this error? Gerard - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
