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


Help: OASIS Mailing Lists Help | MarkMail Help

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: SAX 2.0 enhancement proposal

David Brownell wrote:

> (surely you can spell my name right, Rbo :)

> I still feel like you're ignoring my basic point:  if that draft expects
to interpret
> those identifiers in conflict with clear language in the XML
specification, the
> bug is in that draft, not SAX.  From false assumptions, anything can

You are, of course, entitled to your opinion and if you think the draft spec
is wrong then you should certainly raise your concerns with the OASIS Entity
Resolution TC.  I am taking a slightly different stance in that I think that
they [the TC] should be entitled to use all the information items from the
xml document they deem appropriate.  Most native APIs already make this
information available and nobody has complained that these other APIs are
encouraging non-standard use of XML.

> > James Clark pointed out [1] that the proposal (with his modifications)
moves SAX
> > more into line with the XML Infoset specification [2].
> But that would apply only to UNPARSED entities (or presumably notations).
> See my separate followup -- handling of entities that are PARSED by an
> XML parser is subject to different treatment, even in the infoset.

Perhaps you are right, the Infoset could be enhanced in this area.  I think
the Infoset doesn't address the issue of parsed entity information items
because entity resolution is considered to be performed at the xml processor
level and the Infoset deals with information items presented to levels above
that.  However, the fact that baseURI and system identifier are part of the
infoset for unparsed entities and unexpanded entities implies that the same
would hold true for parsed entities if the infoset said anything about them
at all.

> I don't think it's a good thing for an XML API to address users who want
> nonconformance with the XML specification.

Agreed.  We just disagree on the validity of what the TC want to do.

> If a feature is that all-fired important, then it's worth formally
revising the XML specification (and infoset).

While I would have no problem with the Infoset being clarified, I don't
believe it is necessary.  In this case I think it is SAX that has
interpreted the specification wrongly.

Kind regards
Rob Lugt
ElCel Technology