Fw: SAX 2.0 enhancement proposal

[David Brownell <david-b@pacbell.net>]

Rob forwarded Paul's comments of last Friday, but not my followup ..

> Forwarded to xml-dev...

... so here's another take.  I've not seen any motion to address the
points I've made, which include cases where both the XML and
infoset specs seem to undermine or preclude Paul's interpretation.

For the record, my initial reaction to Rob's proposal was that it
shouldn't be trouble, but then as I looked at it more closely I
started to see too much evidence that this is a situation where
the best response for SAX is "ain't broke, don't fix it" ... at
least, without updating the XML and infoset specs to make clear
that something is broke.


----- Original Message ----- 
From: "David Brownell" <david-b@pacbell.net>
To: "Paul Grosso" <pgrosso@arbortext.com>; "Rob Lugt" <roblugt@elcel.com>
Cc: <entity-resolution-comment@lists.oasis-open.org>
Sent: Friday, June 15, 2001 10:40 AM
Subject: Re: SAX 2.0 enhancement proposal


> > About half of the OASIS Entity Resolution Technical Committee
> > (ERTC) are active members of the W3C XML Core Working Group,
> > the group with the responsibility for maintaining and 
> > interpreting the XML 1.0 Recommendation as well as developing
> > the Infoset spec.
> 
> That's good -- if you're keen on ensuring that your interpretation
> is permissible, then you can easily update the relevant specs to
> suit your requirements.  (Except SAX.)
> 
> 
> > Whereas reasonable people may disagree on the interpretation
> > of something in almost any written work, David's viewpoint 
> 
> Whereas David is "reasonable people" ... who's unreasonable?
> 
> 
> > of what is in compliance with the XML Recommendation is not 
> > shared by a fair number of the W3C XML Core Working Group 
> > members.
> 
> If that's so, then I think it's time to update the spec to preclude
> such interpretations.  As I've said from the start of this discussion.
> 
> That is, assuming "a fair number" is an appropriate majority, which
> understands that the current spec language (and interpretations
> like those I've articulated) underlies a popular XML parser API,
> and changing this will entail changes to most existing XML parser
> infrastructure in at least one major XML programming language.
> 
> Normally, that sort of situation is one where I'm used to seeing
> spec changes be refused because of the severe tire damage.
> 
> Or when such changes are made, they must be _very_ important.
> (And I can't see that minor type of catalog feature being that
> important, but opinions can clearly differ.  Catalogs have worked
> fine without needing that particular subfunctionality.)
> 
> 
> >     As far as the Infoset, the XML Core WG also wrote 
> > that specification (the original editor of that spec being one 
> > of the key members of the OASIS Entity Resolution Technical 
> > Committee), and most of us don't believe that anything therein 
> > is contrary to the positions taken in the XML Catalog draft.
> 
> And have they all looked at the specific issues I've raised,
> then?  Or is that just an un-examined assumption that this
> team of folk can't possibly have made a mistake?  I see
> no evidence anyone looked at those issues.  And I've turned
> up enough problems with the XML spec, particularly its
> entity handling, that I know such problems do happen.
> (Heck, any spec has problems.  I just happen to know
> that many of the XML spec troubles relate to entities.)
> 
> So I think it's an _extremely_ reasonable expectation that if
> you choose to reject my interpretations (see the xml-dev
> archives on this topic), W3C processes should update the
> various specs, in the various areas I've made the effort
> to identify.
> 
> It'd also be good to see concrete disproof of the points I've
> raised; I don't take well to vague invocations that "a fair
> number" of people disagree, particularly when I provide
> specific spec references.  I have been known to handle
> to-the-point responses quite nicely, however.
> 
> - Dave
> 
>