[
Lists Home |
Date Index |
Thread Index
]
At 5:38 PM -0500 2/18/04, Norman Walsh wrote:
>So just recently, when Michael Glavassevich pointed out[1] on the
>sax-devel list why the extension framework is insufficient for our
>needs, I became deeply concerned.
Michael's claim is that properly supporting XML 1.1 requires placing
xmlns:prefix attributes in a namespace. I disagree. Certainly the
namespaces 1.1 specification does make a backwards incompatible
change, and does clearly place these attributes in a namespace,
unlike the Namespaces 1.0 specification and unlike SAX 2.0.
However, all that's really needed is for SAX to correctly and
consistently report namespace declarations. It does not necessarily
need to assign the same (or any) namespace URI to these prefixes that
the spec suggests. The current SAX approach to handling namespace
declarations and namespace declaration attributes is not a problem.
All attributes are properly reported. if someone really wants to
assign a namespace URI to these attributes, they can write the extra
code to do so when they move them into a new environment. However,
doing so now would be gratuitously incompatible with the large
existing base of SAX programs. It's annoying situation, yes (I blame
the DOM and XML core working groups for letting this change through
in the first place) but the proposed cure is much worse than the
disease.
>For better or worse, a JSR is not simply a specification exercise. We
>must ship a reference implementation. To make matters worse, a hard
>deadline has been imposed on JSR 206. So we have significant,
>practical challenges to overcome in a fairly short period of time.
>
>I don't know what to do and neither, as far as I can determine, do the
>members of the expert group.
>
>A number of possibilities occur to me, none of them very attractive:
>
>1. We could decide not to support XML 1.1 and Namespaces 1.1. The changes
> in XML 1.1 are small, the RI team has worked to address them, and
> the specifications are now recommendations. I think the argument that
> we should abandon our position of supporting them because a few changes
> are needed in the SAX API would be a hard sell.
Given your hard deadline, and the apparent unavailability of the
Davids, this is what I recommend.
>2. JSR 206 could fork SAX, producing javax.xml.sax.* classes, for example.
> This would be "honest" in the sense that we would not be changing an
> API that we are not empowered to change. But it would be bad.
Double plus ungood, in fact.
>3. The developer community could endorse our EG to make the few small changes
> needed to SAX to support XML 1.1 and Namespaces 1.1. Unlikely, I fear.
>
>4. The developer community could modify SAX to support XML 1.1 and
> Namespaces 1.1. That would be best, but I'm uncomfortable with the prospect
> of achieving that within the schedule I have to meet.
I think what this is demonstrating is that the SAX process needs to
become a little more formalized. However, that is unlikely to happen
within Sun's deadline. Unless someone can reach one of the Davids and
get them to respond, then your only real options are to either except
the current unfinished SAX extensions or to simply ship SAX 2.0. I'm
honestly not sure that is such a bad idea. While version
identification would be nice, I don't see anything crippling in SAX
when it comes to XML 1.1. A 1.1 parser using SAX would just pass data
to some methods where an XML 1.0 parser would have thrown an
exception. In a few rare cases, the 1.1 parser would call
ignorableWhitespace() where a 1.0 parser would call characters()
instead. So I guess I'm really suggesting
5. Ship a 1.1 parser that uses the SAX 2.0 interfaces as designed,
does not report version information, and does not assign xmlns:prefix
attributes to a namespace by default.
Either that or don't support XML 1.1/Namespaces 1.1 at all.
--
Elliotte Rusty Harold
elharo@metalab.unc.edu
Effective XML (Addison-Wesley, 2003)
http://www.cafeconleche.org/books/effectivexml
http://www.amazon.com/exec/obidos/ISBN%3D0321150406/ref%3Dnosim/cafeaulaitA
|
