[XML-DEV Mailing List Archive Home] [By Thread] [By Date] [Recent Entries] [Reply To This Message]

Re: SAX 2.0 enhancement proposal

  • From: David Brownell <david-b@p...>
  • To: Rob Lugt <roblugt@e...>, xml-dev@l...
  • Date: Wed, 13 Jun 2001 17:52:09 -0700

Re: SAX 2.0 enhancement proposal
By the way, having skimmed the 12-June-2001 draft of that OASIS
proposal, I don't see where it said that it needs relative URIs as inputs.

Lots of text talking about use of relative URIs internal to the catalog,
but nothing about such critters as inputs to the algorithms.  That would
seem to be a problem in that draft.  (Clearly I'd say to define the inputs
as excluding relative URIs.)


Rob Lugt responded:

> Norman Walsh and Paul Grosso have posted replies that clearly indicate that
> what the XML Catalog spec is suggesting is a perfectly valid thing to do.  I
> agree with them.

On the other hand, I found their responses to be off-target.  Paul seemed
to think that I was saying that remapping was wrong (it isn't, or else web
caching couldn't work), and Norm responded as if I was talking about the
ID-to-data mapping (I wasn't).  Those parts of what that catalog draft is
talking about are fine -- and fully supported even by SAX 1.0 parsers.

The issue is what relative URIs denote in a context where there there's
unambiguous text in the XML 1.0 (2e++) spec.  That is, relative URIs
in system literals, before a catalog/resolver/... would see them.


> Moreover, I disagree with your position about SAX "permitting" something, as
> if it had a moral duty to withhold certain information.  SAX is an API and
> nothing more.  

It's an XML API, and I have a hard time seeing why it should be torqued
to address requirements that I read the XML spec as precluding.  There's a
cost to such changes (including XML spec revision), and in this case I've
seen no evidence of a real problem motivating any change whatever.

Let me turn it around:  If the XML spec says something works a particular
way, who wins by encouraging tools to work in some non-conformant way?
Surely not the XML community.


> Certainly SAX was not intended to report all the document properties that
> may be of interest to every application (hence the 'simple' in its title),
> it had to draw the line somewhere.  But the line was drawn to include entity
> resolution.  Now that we are seriously trying to use SAX to accomplish
> entity resolution a flaw has been found.

I've never once had a problem using the SAX EntityResolver in that role,
but then again I was working within the constraints of the XML 1.0 spec.

- Dave





PURCHASE STYLUS STUDIO ONLINE TODAY!

Purchasing Stylus Studio from our online shop is Easy, Secure and Value Priced!

Buy Stylus Studio Now

Download The World's Best XML IDE!

Accelerate XML development with our award-winning XML IDE - Download a free trial today!

Don't miss another message! Subscribe to this list today.
Email
First Name
Last Name
Company
Subscribe in XML format
RSS 2.0
Atom 0.3
 

Stylus Studio has published XML-DEV in RSS and ATOM formats, enabling users to easily subcribe to the list from their preferred news reader application.


Stylus Studio Sponsored Links are added links designed to provide related and additional information to the visitors of this website. they were not included by the author in the initial post. To view the content without the Sponsor Links please click here.

Site Map | Privacy Policy | Terms of Use | Trademarks
Free Stylus Studio XML Training:
W3C Member
Stylus Studio® and DataDirect XQuery ™are products from DataDirect Technologies, is a registered trademark of Progress Software Corporation, in the U.S. and other countries. © 2004-2013 All Rights Reserved.