OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.


Help: OASIS Mailing Lists Help | MarkMail Help



   SAX survey: expected local name for non-namespace qualifiedelements

[ Lists Home | Date Index | Thread Index ]


Recently I raised some issues about inconsistencies in the SAX 
documentation with regard to how local names are reported to the 
startElement() method:

public void startElement(java.lang.String uri,
                          java.lang.String localName,
                          java.lang.String qName,
                          Attributes atts)
                   throws SAXException

Specifically the question is, when namespace processing is turned on 
as it is by default (i.e. when http://xml.org/sax/features/namespaces 
is true), is it acceptable for a parser to report the local name of a 
non-namespace qualified element as the empty string? For example, 
consider this document with no namespaces:


When a parser calls startElement() or endElement() for these 
elements, is it allowed to report their local names as the empty 
string, and only provide the name as the qName argument? Or must it 
report the local names as "document" and "para"?

David Brownell, the current maintainer of SAX, surprised me by 
claiming that it is OK to report the local names as the empty string 
for non-qualified elements even when the namespaces feature is true. 
He says that such elements do not have local names.

I've checked with 4 existing parsers (Xerces-2, Piccolo, Crimson in 
JDK 1.4, and Oracle and they all report the actual name as 
the local name argument. The SAX documentation is contradictory on 
this point. The infoset clearly states that non-namespace qualified 
elements do have local names, but the infoset is not normative for 

Here is the question:

1. Before now, what was your understanding of this point? When 
writing and teaching did you tell your students to rely on local 
names or qNames for non-namespace qualified elements? What have you 
relied on in your code?

2. If you've implemented a parser, what does your parser do?

3. If you participated in the original specification of SAX2 back in 
1999/2000 what were you thinking about this then?

Note that the question is *not* what SAX should do now. The question 
is what was people's understanding of this point so that going 
forward we can be clearer about what is and is not conformant, and so 
that we can all write interoperable code. I'm trying to understand as 
much as possible what the original intent of SAX2 was, and I'm hoping 
that we don't discover that 50% of people understood it one way and 
50% understood it the opposite way, though that's certainly possible.

I've cc'd this to various people who have been involved in SAX in one 
way or another, as well as posting it to the sax-devel, xerces-j-dev, 
and xml-dev mailing lists. Discussion should probably take place on 
sax-devel <http://lists.sourceforge.net/lists/listinfo/sax-devel>, 
but it will where it will. Thanks for your input.

If you'd like to read the original exchange that led to this question 
see http://www.geocrawler.com/lists/3/SourceForge/13179/0/ and start 
with the first post on "misleading sentence on project page"

| Elliotte Rusty Harold | elharo@metalab.unc.edu | Writer/Programmer |
|          The XML Bible, 2nd Edition (Hungry Minds, 2001)           |
|             http://www.cafeconleche.org/books/bible2/              |
|   http://www.amazon.com/exec/obidos/ISBN=0764547607/cafeaulaitA/   |
|  Read Cafe au Lait for Java News:  http://www.cafeaulait.org/      |
|  Read Cafe con Leche for XML News: http://www.cafeconleche.org/    |


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

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