Altova Mailing List Archives

Re: URIs as IDs in ModSAX (was Re: ModSAX (SAX 1.1) Proposal) (fwd)

From: Dan Brickley <Daniel.Brickley@-------.--.-->
To: "'xml-dev@--.--.--'" <-------@--.--.-->
Date: 2/17/1999 7:47:00 PM
On Wed, 17 Feb 1999, Robb Shecter wrote:

> > From: David Megginson <david@m...>
> >  > Justification:
> >  >      setFeature needs to be passed an identifying string that
> >  >      uniquely picks out some property. Rather than go with the
> >  >      pseudo-uri's in Java, it would be more in the spirit of XML
> >  >      and Web to use URIs. Using URIs is also more friendly towards
> >  >      non-Java implementations of the SAX API.
> >
> > I'm strongly inclined to agree.  Does anyone have a strong case
> > against?
> Hi,
> I'm joining the discussion a bit late, but it seems to me that allowing something that looks
> like a URL that's not a URL is a bad idea.  This seems to have introduced unnecessary
> confusion into namespaces:  It makes an accompanying explanation and admonishment necessary

That was not the proposal. The proposal was to allow SAX features to
be individuated using Uniform Resource Identifiers (URIs). URIs are a
superset of URLs and URNs, so a non-URL URI might be used. The XML-Data 
proposal, admirably, used uuid: URIs to make this point.
(eg.  urn:uuid:BDC6E3F0-6DA3-11d1-A2A3-00AA00C14882/ )

Excerpt from RFC 2396 Uniform Resource Identifiers (URI): Generic Syntax
available from

   A Uniform Resource Identifier (URI) is a compact string of characters
   for identifying an abstract or physical resource.  
   This document defines a grammar that is a superset of all valid URI,
   such that an implementation can parse the common components of a URI
   reference without knowing the scheme-specific requirements of every
   possible identifier type

> ("Don't assume there's anything at this 'not-URL' ").  From a software engineering point of

(I'd argue that software engineers who write code that assumes all URLs
can be unproblematically de-referenced are asking for trouble. but
that's besides the point)

> view,  I think it'd be better to chose something that doesn't require the extra documentation
> - Instead of saying, "Watch out for the problem here...", we should not create the problem in
> the first place.

We are not creating a problem. It is fine to use a URL to identify a SAX
property, but by choosing to allow _all_ forms of URI we leave room for
other approaches. This echoes the approach taken by XML namespaces.

Again, from the URI spec:

         A resource can be anything that has identity.  Familiar
         examples include an electronic document, an image, a service
         (e.g., "today's weather report for Los Angeles"), and a
         collection of other resources.  Not all resources are network
         "retrievable"; e.g., human beings, corporations, and bound
         books in a library can also be considered resources classes, perl modules, sax filters are equally 'resources' by
this definition.

> I think that the Java standard is very good. I don't think that it's unfriendly towards
> non-Java implementations:  it is after all, only a standard, and not hardcoded into the
> language.

I disagree. The string '' is as meaningless in the Java 
community as in the wider world. The Java package naming convention has
the look but not the substance of a hieararchically managed namespace.
'' does not uniquely name anything except within the
context of a group of consenting adults who've agreed a set of
conventions for doing so. I don't think the Java world have agreed to do
this yet. The Web approach, using URIs, seems mor mature than Java's
way of doing so. (Maybe a URI scheme for Java package/class naming might
be on the cards for Java 3...?)

>  The main problem with it is that users who do not have a measure of authority at
> their organization can have problems.  So, for example, I've released some open source code
> with the package name:
> org.acm.robb
> ...because I have the e-mail address robb@a....  That works until the ACM decides to put a
> host named "robb" on the acm network.  (OK, that may not happen :) - but the point is valid.)

Quite! That's the problem URIs address, at least within the context of
the Web.
> So, I'm for a clear format, maybe Java-like, that --doesn't-- resemble a URL, that solves the
> above issue.

URIs do this. Though I really don't see a problem with using URIs that
are URLs, so long as we bear in mind that knowing the URL for a resource
is not, and never has been, a guarantee that you'll be able to
de-reference it. For example, there may well be an resource in URL (and hence URI) space,
but I'm unlikely to ever be able to access it. Similarly, might serve
to name a SAX module. 

The fact that HTTP allows for content negotiation of language & format
specific views into resources in the http://* namespace also buys some
room to think. You could have english, french and german HTML docs, or
text/xml or application/java-serialised-class or whatever, all
accessible (or not; dereferencing isn't a right) via the same abstract
URL. URLs can be a lot more abstract than people give credit for...


ps. one last excerpt from the URI spec; sorry if I'm doing this point to

from section 1.2. URI, URL, and URN

   Although many URL schemes are named after protocols, this does not
   imply that the only way to access the URL's resource is via the named
   protocol.  Gateways, proxies, caches, and name resolution services
   might be used to access some resources, independent of the protocol
   of their origin, and the resolution of some URL may require the use
   of more than one protocol (e.g., both DNS and HTTP are typically used
   to access an "http" URL's resource when it can't be found in a local

xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@i...
Archived as: and on CD-ROM/ISBN 981-02-3594-1
To (un)subscribe, mailto:majordomo@i... the following message;
(un)subscribe xml-dev
To subscribe to the digests, mailto:majordomo@i... the following message;
subscribe xml-dev-digest
List coordinator, Henry Rzepa (mailto:rzepa@i...)


These Archives are provided for informational purposes only and have been generated directly from the Altova mailing list archive system and are comprised of the lists set forth on Therefore, Altova does not warrant or guarantee the accuracy, reliability, completeness, usefulness, non-infringement of intellectual property rights, or quality of any content on the Altova Mailing List Archive(s), regardless of who originates that content. You expressly understand and agree that you bear all risks associated with using or relying on that content. Altova will not be liable or responsible in any way for any content posted including, but not limited to, any errors or omissions in content, or for any losses or damage of any kind incurred as a result of the use of or reliance on any content. This disclaimer and limitation on liability is in addition to the disclaimers and limitations contained in the Website Terms of Use and elsewhere on the site.