sax-devel Mailing List for SAX: Simple API for XML (Page 3)
Brought to you by:
dmegginson
You can subscribe to this list here.
2001 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
(6) |
Aug
(52) |
Sep
(3) |
Oct
(29) |
Nov
(97) |
Dec
(5) |
---|---|---|---|---|---|---|---|---|---|---|---|---|
2002 |
Jan
(55) |
Feb
(33) |
Mar
(3) |
Apr
(32) |
May
(92) |
Jun
(51) |
Jul
(3) |
Aug
(4) |
Sep
(6) |
Oct
(6) |
Nov
(3) |
Dec
(6) |
2003 |
Jan
(5) |
Feb
(2) |
Mar
(1) |
Apr
(16) |
May
|
Jun
(14) |
Jul
(3) |
Aug
(2) |
Sep
|
Oct
(3) |
Nov
(12) |
Dec
(3) |
2004 |
Jan
(4) |
Feb
(34) |
Mar
(54) |
Apr
(143) |
May
|
Jun
(7) |
Jul
(2) |
Aug
|
Sep
(1) |
Oct
|
Nov
(4) |
Dec
(6) |
2005 |
Jan
(11) |
Feb
|
Mar
|
Apr
(1) |
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
2006 |
Jan
(2) |
Feb
(6) |
Mar
(2) |
Apr
|
May
(10) |
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
(2) |
Dec
(1) |
2007 |
Jan
|
Feb
|
Mar
(1) |
Apr
|
May
|
Jun
(1) |
Jul
|
Aug
|
Sep
|
Oct
|
Nov
(2) |
Dec
|
2008 |
Jan
|
Feb
|
Mar
|
Apr
(4) |
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
2010 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
(1) |
Sep
|
Oct
|
Nov
|
Dec
|
2011 |
Jan
|
Feb
|
Mar
(1) |
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
From: David M. <dav...@gm...> - 2004-12-02 02:50:52
|
On Fri, 19 Nov 2004 16:22:39 -0500, Elliotte Harold <el...@me...> wrote: > The JavaDoc for InputSource states, "If neither a character stream nor a > byte stream is available, the parser will attempt to open a URI > connection to the resource identified by the system identifier." > > I suspect at some point someone did a find and replace for URL/URI in > the Javadoc. However. there's no such thing as a "URI connection". This > should read "URLConnection" or perhaps "URL connection", but it > definitely is a URL connection, not a URI connection. > > David, could you fix this in CVS please? Thanks. Done -- thanks. All the best, David -- http://www.megginson.com/ |
From: Elliotte H. <el...@me...> - 2004-11-19 21:22:43
|
The JavaDoc for InputSource states, "If neither a character stream nor a byte stream is available, the parser will attempt to open a URI connection to the resource identified by the system identifier." I suspect at some point someone did a find and replace for URL/URI in the Javadoc. However. there's no such thing as a "URI connection". This should read "URLConnection" or perhaps "URL connection", but it definitely is a URL connection, not a URI connection. David, could you fix this in CVS please? Thanks. -- Elliotte Rusty Harold el...@me... XML in a Nutshell 3rd Edition Just Published! http://www.cafeconleche.org/books/xian3/ http://www.amazon.com/exec/obidos/ISBN=0596007647/cafeaulaitA/ref=nosim |
From: Karl W. <ka...@wa...> - 2004-11-11 14:46:43
|
A belated announcement (I thought this list was more or less dead): The SAX API has been ported to the .NET environment. Check out http://saxdotnet.sourceforge.net A non-validating parser implementation, based on Expat, has been provided as well (package SAXExpat 1.0). Karl |
From: Petr C. <pe...@gi...> - 2004-11-11 14:17:14
|
David Megginson wrote: > >Originally, SAX was designed to work with existing XML parsers -- it >was only later that things turned around and people started designing >parsers to work with SAX. Reporting a position right after the markup >worked best with the existing XML parsers. > >Actually, I'm not sure I see the advantage of reporting a position >before or inside. Ideally, you'd have the whole range (start-end), >but if you cannot have that, one position is just as good as another >for reporting errors to the user. > > I have thought this is quite arbitrary, just hasn't been sure. The reason why I ask is that we are specifying the locator behavior for Perl SAX and we want neither introduce unnecessary differences from Java nor follow the Java API blindly. Thanks, Petr -- Petr Cimprich Ginger Alliance www.gingerall.com |
From: Petr C. <pe...@gi...> - 2004-11-11 10:08:32
|
Hi all, I would like to ask what have been reasons to recommend that SAX drivers should provide the line and column position of the first character _after_ the text associated with the current document event (http://www.saxproject.org/apidoc/org/xml/sax/Locator.html). It appears more natural to provide a position within text associated with the current event, for the first sight. Am I missing some relevant benefits of the way SAX uses to specify the position? Thanks, Petr -- Petr Cimprich Ginger Alliance www.gingerall.com |
From: Elliotte H. <el...@me...> - 2004-09-06 12:25:30
|
Consider this document: <root> <a> <b/> </a> </root> Note the lack of namespace prefixes and defualt namespaces. Will/should/can a SAX parser call ContentHandler.startPrefixMapping() and endPrefixMapping() for this document? In particular shoudl it call startPrefixMapping("", "") for the root element of this document? I don't see anything in the spec squarely on point here. :-( -- Elliotte Rusty Harold |
From: Jochen W. <joc...@fr...> - 2004-07-16 05:58:13
|
Yuval Oren wrote: > What should the following Java code do if run in the same directory as=20 > doc.xml and doc.dtd? Should it be able to find doc.dtd? [...] > reader.parse(new InputSource(new FileInputStream(=93doc.xml=94))); I would personally assume, that you have to use InputSource isource =3D new InputSource(new FileInputStream("doc.xml= ")); isource.setSystemId("doc.xml"); reader.parse(isource); because otherwise there is no such thing like a "base URI". > Case 2 =96 JAXP: >=20 > SAXParser parser =3D ...; >=20 > parser.parse(new FileInputStream(=93doc.xml=94), new DefaultHandler()); In that case, I believe that parser.parse(new File("doc.xml"), new DefaultHandler()); will do the same, because this is implicitly creating an InputSource like= above. Jochen |
From: Yuval O. <yu...@bl...> - 2004-07-16 02:44:51
|
Hi folks, I have a question on "correct" behavior of SAX parsers. Say you have a directory with 2 files in it: doc.xml and doc.dtd. Doc.xml looks like this: <!DOCTYPE doc SYSTEM "doc.dtd"> <doc/> What should the following Java code do if run in the same directory as doc.xml and doc.dtd? Should it be able to find doc.dtd? Case 1 - SAX2: XMLReader reader = .; reader.parse(new InputSource(new FileInputStream("doc.xml"))); Case 2 - JAXP: SAXParser parser = ...; parser.parse(new FileInputStream("doc.xml"), new DefaultHandler()); Different parsers seem to exhibit different behavior. Piccolo currently doesn't find the file in either case, since it doesn't assume a base URI. Should I change this? Thanks, Yuval |
From: Karl W. <ka...@wa...> - 2004-06-16 14:14:27
|
After having gotten some positive feedback (mostly off-list) about unifying the "version 2" extension interfaces with the original ones, I am having second thoughts, mostly because of this: As far as I can tell, the SAX extensions are meant to include interfaces for reporting parts of an XML document that the XML spec does not explicitly require to be reported. Unifying these interfaces - IAttributes(2), ILocator(2) and IEntityResolver(2) - would break the semantics behind this separation of modules/namespaces. Another option could be to simply pack everything into one namespace - without any separation on the definition level - and document which parts an XML processor is required to support and which ones are optional. Not sure, currently. Karl |
From: Karl W. <ka...@wa...> - 2004-06-13 20:56:40
|
----- Original Message ----- From: "Elliotte Rusty Harold" <el...@me...> To: "Karl Waclawek" <ka...@wa...> Cc: <sax...@li...> Sent: Sunday, June 13, 2004 3:11 PM > At 2:11 PM -0400 6/13/04, Karl Waclawek wrote: > > >What would you then say about moving ILexicalHandler and > >IDeclHandler into the core as well, or in other words, > >eliminating the notion of core vs. extensions? > > The problem with doing that is that it requires parsers to support > these extensions. If you're comfortable with that, OK, but it is > extra work for impleenters, especially at first. There's also an > extent to which these provide content that applications really > shouldn't rely on or use in a major way. I undeerstand this point. My reason for asking was basically that the same argument could be applied to the IAttributes2, ILocator2 and IEntityResolver2 interfaces. So the question is: which extensions really *are* extensions? Karl |
From: Elliotte R. H. <el...@me...> - 2004-06-13 19:22:16
|
At 2:11 PM -0400 6/13/04, Karl Waclawek wrote: >What would you then say about moving ILexicalHandler and >IDeclHandler into the core as well, or in other words, >eliminating the notion of core vs. extensions? The problem with doing that is that it requires parsers to support these extensions. If you're comfortable with that, OK, but it is extra work for impleenters, especially at first. There's also an extent to which these provide content that applications really shouldn't rely on or use in a major way. -- Elliotte Rusty Harold el...@me... Effective XML (Addison-Wesley, 2003) http://www.cafeconleche.org/books/effectivexml http://www.amazon.com/exec/obidos/ISBN%3D0321150406/ref%3Dnosim/cafeaulaitA |
From: Karl W. <ka...@wa...> - 2004-06-13 18:11:57
|
----- Original Message ----- From: "Elliotte Rusty Harold" <el...@me...> To: "Karl Waclawek" <ka...@wa...> Cc: <sax...@li...> Sent: Saturday, June 12, 2004 8:57 PM > Sounds reasonable given the lack of legacy issues. I'd also suggest > eliminating all the deprecated interfaces from SAX1 if you haven't > already. What would you then say about moving ILexicalHandler and IDeclHandler into the core as well, or in other words, eliminating the notion of core vs. extensions? Karl |
From: Karl W. <ka...@wa...> - 2004-06-13 01:50:35
|
----- Original Message ----- From: "Elliotte Rusty Harold" <el...@me...> To: "Karl Waclawek" <ka...@wa...> Cc: <sax...@li...> Sent: Saturday, June 12, 2004 8:57 PM > Sounds reasonable given the lack of legacy issues. I'd also suggest > eliminating all the deprecated interfaces from SAX1 if you haven't > already. Yes, that was the first thing we did. :-) Karl |
From: Elliotte R. H. <el...@me...> - 2004-06-13 00:58:27
|
Sounds reasonable given the lack of legacy issues. I'd also suggest eliminating all the deprecated interfaces from SAX1 if you haven't already. -- Elliotte Rusty Harold el...@me... Effective XML (Addison-Wesley, 2003) http://www.cafeconleche.org/books/effectivexml http://www.amazon.com/exec/obidos/ISBN%3D0321150406/ref%3Dnosim/cafeaulaitA |
From: Karl W. <ka...@wa...> - 2004-06-12 21:29:36
|
When porting the SAX API to the .NET environment - http://saxdotnet.sf.net - we decided to stay pretty close to the original specs. However, we have had some feedback that it would be more appropriate to consolidate some of the SAX extensions back into the core, as there is no legacy to consider, and one should not start with interface versions right from the beginning. Which means: We would only have IAttributes, ILocator and IEntityResolver interfaces, but comprising all the signatures of the original IAttributes2, ILocator2 and IEntityResolver2 interfaces. For those of you interested in .NET, what do you think about that proposal? Karl |
From: David M. <dm...@at...> - 2004-04-28 20:53:05
|
The zipfile for sax2r3 on SourceForge was messed up so that source code and javadoc were mixed together. I've fixed that and replaced the zip file on SourceForge (same release, same file name, different file). I recommend that everyone wait until tomorrow for the fixed file to propagate to the mirrors, then download the replacement. If you're in a desperate hurry, the updated file has already made it to here: http://osdn.dl.sourceforge.net/sourceforge/sax/sax2r3.zip You can verify that you have the right file by looking for a docs/javadoc directory containing all of the JavaDoc documentation. Apologies, David |
From: <mik...@ho...> - 2004-04-28 14:01:15
|
On Wed, 28 Apr 2004, Elliotte Rusty Harold wrote: > It's defined in section 4 of the Namespaces specification using BNF: > > Bottom line: a qualified name is any XML name that does not contain an initial > or trailing colon, or more than one colon, or use a non-namestart character > after its only colon. This is the syntax of a qualified name, but it doesn't give the whole semantics. > An element name in a document that does not use namespaces is still a > perfectly legal qualified name, provided only that it does not use > colons in a way incompatible with the namespaces specification. Yes, but is it OK to use qName=localName when there are namespaces? E.g. is this OK? aContentHandler.startElement("http://www.foo.com/ns1", "rec", "rec", a1); aContentHandler.startElement("http://www.foo.com/ns2", "el2", "el2", a2); aContentHandler.startElement("", "el3", "el3", a3); |
From: Karl W. <ka...@wa...> - 2004-04-28 13:35:02
|
----- Original Message ----- From: "Elliotte Rusty Harold" <el...@me...> To: "David Megginson" <dm...@at...> Cc: "SAX Developers' List" <sax...@li...> Sent: Wednesday, April 28, 2004 5:21 AM > It would be useful to begin immediately working on SAX 2.0.3 since > there are a lot of leftover niggling little issues we should fix, > ranging from trivial things like the proper capitalization of > "namespace" to major issues such as whether or not parsers are > required to call endDocument() after a fatal error. Sadly there are > also now some broken parts we can't fix because 2.0.2 has locked them > in, like the Locator2 interface. :-( If one agrees ... > Toward this end, it would be very helpful if we could start using the > Bug database at sourceforge to track these things. For myself, I know > I can't really keep track of what I have and have not reported, much > less what others have. If we continue in the current informal post to > the mailing list fashion (especially with list archives down) then > when we do open up work on SAX 2.0.3, I just know I'm going to > resubmit at least three things that have already been rejected, and > forget about at least three others. I agree with that. About the archives - I think a bug/support request should be issued here: http://sourceforge.net/tracker/?func=add&group_id=1&atid=200001 I believe such a request should come from one of the project administrators or members rather than from a project user. Karl |
From: Karl W. <ka...@wa...> - 2004-04-28 13:08:03
|
----- Original Message ----- From: "Elliotte Rusty Harold" <el...@me...> To: "Mikael Ståldal" <mik...@ho...> Cc: <sax...@li...> Sent: Wednesday, April 28, 2004 5:07 AM > Indeed the SAX specification might be clearer if > we just called that argument "name" rather than > "qName". As it stands, a document that is > namespace incompatible due to multiple colons in > element names can't really be processed by SAX > because such an element has neither a local part > nor a qualified name. However, it does have a > name, and is well-formed though not namespace > well-formed. This raises the question: if the namespaces feature is turned off, is a SAX processor still in "namespace processing" mode? That is, should it report violations of namespace well-formedness? If not, then the term "qName" really should be called "name" with the understanding that it is a qualified name when namespaces are turned on. Personally, I would have preferred the Expat approach of passing local name, URI and prefix. Fewer chances for confusion. Karl |
From: Elliotte R. H. <el...@me...> - 2004-04-28 09:30:07
|
At 9:46 AM +0200 4/28/04, Mikael St=E5ldal wrote: >What *is* a qualified name then? And where is that specified? It's defined in section 4 of the Namespaces specification using BNF: In XML documents conforming to this=20 specification, some names (constructs=20 corresponding to the nonterminal Name) MUST be=20 given as qualified names, defined as follows: Qualified Name [6] QName ::=3D PrefixedName | UnprefixedName [6a] PrefixedName ::=3D Prefix ':' LocalPart [6b] UnprefixedName ::=3D LocalPart [7] Prefix ::=3D NCName [8] LocalPart ::=3D NCName Bottom line: a qualified name is any XML name=20 that does not contain an initial or trailing=20 colon, or more than one colon, or use a=20 non-namestart character after its only colon. An=20 element name in a document that does not use=20 namespaces is still a perfectly legal qualified=20 name, provided only that it does not use colons=20 in a way incompatible with the namespaces=20 specification. Indeed the SAX specification might be clearer if=20 we just called that argument "name" rather than=20 "qName". As it stands, a document that is=20 namespace incompatible due to multiple colons in=20 element names can't really be processed by SAX=20 because such an element has neither a local part=20 nor a qualified name. However, it does have a=20 name, and is well-formed though not namespace=20 well-formed. -- Elliotte Rusty Harold el...@me... Effective XML (Addison-Wesley, 2003) http://www.cafeconleche.org/books/effectivexml http://www.amazon.com/exec/obidos/ISBN%3D0321150406/ref%3Dnosim/cafeaulai= tA |
From: Elliotte R. H. <el...@me...> - 2004-04-28 09:30:06
|
It would be useful to begin immediately working on SAX 2.0.3 since there are a lot of leftover niggling little issues we should fix, ranging from trivial things like the proper capitalization of "namespace" to major issues such as whether or not parsers are required to call endDocument() after a fatal error. Sadly there are also now some broken parts we can't fix because 2.0.2 has locked them in, like the Locator2 interface. :-( Toward this end, it would be very helpful if we could start using the Bug database at sourceforge to track these things. For myself, I know I can't really keep track of what I have and have not reported, much less what others have. If we continue in the current informal post to the mailing list fashion (especially with list archives down) then when we do open up work on SAX 2.0.3, I just know I'm going to resubmit at least three things that have already been rejected, and forget about at least three others. I suggest beginning by pruning the existing bugs and RFEs. Looking at it now, there are only two unresolved bugs and one and perhaps both of them should simply be closed with no further action. I haven't read all the RFEs, but some of them can likewise simply be closed. Others we may want to consider for SAX 2.0.3. -- Elliotte Rusty Harold el...@me... Effective XML (Addison-Wesley, 2003) http://www.cafeconleche.org/books/effectivexml http://www.amazon.com/exec/obidos/ISBN%3D0321150406/ref%3Dnosim/cafeaulaitA |
From: <mik...@ho...> - 2004-04-28 07:48:17
|
On Tue, 27 Apr 2004, David Megginson wrote: > SAX 2.0.2 (saxr3) should soon be available from the SourceForge project page: The distribution contains an empty "javadoc" directory. |
From: <mik...@ho...> - 2004-04-28 07:47:04
|
On Tue, 27 Apr 2004, Elliotte Rusty Harold wrote: > You would not have to do this. You would just pass the local name for each > argument. That is you'd pass the same String object twice in the method call. > A qualified name is *not* a prefixed name, though the SAX docs are misleading > on this point, and we should probably fix that too. What *is* a qualified name then? And where is that specified? |
From: David M. <dm...@at...> - 2004-04-28 01:24:06
|
David Megginson wrote: > SAX 2.0.2 (saxr3) should soon be available from the SourceForge project > page: > > http://www.sourceforge.net/sax/ That should be http://www.sourceforge.net/projects/sax/ Apologies for any confusion, David |
From: David M. <dm...@at...> - 2004-04-28 01:09:39
|
SAX 2.0.2 (saxr3) should soon be available from the SourceForge project page: http://www.sourceforge.net/sax/ There are no changes from the sax2r3-pre2 release, other than updates to the version number in text files. This mini-release is intended mainly to add support for XML 1.1 and Namespaces 1.1, including Unicode normalization. The changes are all in features, properties, and JavaDoc, not in the actual class and method signatures; since the new features and properties are optional, existing libraries should continue to work with the new release. See the CHANGES and ChangeLog files for details. Many thanks to everyone who helped with this release, both on the sax-devel and xml-dev mailing lists. All the best, David Megginson (temporarily filling in as SAX maintainer) |