Altova Mailing List Archives


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 4:30:00 PM
This and previous forwarded from an (accidentally!) off-list discussion.

To recap, the proposal is that SAX feature identifiers are typed as URI
(ie. superset of URLs and URNs) to give a globally managed namespace,
without associating additional semantics with those names. 

Dan

---------- Forwarded message ----------
Date: Wed, 17 Feb 1999 09:50:22 -0500 (EST)
From: David Megginson <david@m...>
To: Dan Brickley <Daniel.Brickley@B...>
Subject: URIs as IDs in ModSAX (was Re: ModSAX (SAX 1.1) Proposal)

Dan Brickley writes:

 > Here's a small proposal:
 >  
 > >     public abstract void setFeature (String featureID, boolean state)
 > 
 > becomes public abstract void setFeature (URI featureID, boolean state)
 > 
 > (or leave as String but with understanding that the datatype of
 > featureID is anything that's a legal Web URI)

Yes, using URIs was my original idea, and I'm still very partial to
it; I've been using the Java-package-style names in my examples, but
I'd like to know what everyone thinks about the issue.

I'd prefer not the use the java.net.URL class, though -- I don't think 
it buys us anything, since the URIs are not mean to be dereferenced.

 > 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?


All the best,


David

-- 
David Megginson                 david@m...
           http://www.megginson.com/


xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@i...
Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ 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...)

Disclaimer

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 www.altova.com/list/index.html. 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.