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

RE: Paul has volunteered (was Re: Overloaded URIs must GO!)

  • From: "Hunter, David" <dhunter@M...>
  • To: 'David Megginson' <david@m...>, 'XML Dev' <xml-dev@i...>
  • Date: Mon, 31 May 1999 10:42:20 -0400

my credit card number is
David Megginson writes:
> The phone number for my business is 1-613-722-4697.  Let's say (for
> the sake of argument) that my credit card number is 161 3722 4697, and
> that my Social Insurance number is 1613 7224 697 (it wouldn't be,
> because Canadian SIN's are only nine digits long, but just pretend).
> 
> Now, is there any problem with the fact that my business phone number,
> my credit card number, and my SIN are digit-for-digit the same?
> 
> In principle, the same thing applies to using URLs as unique
> identifiers -- I (should) always know whether I'm dealing with a link
> or a namespace, so there should be no room for confusion: links point
> to resources that can be retrieved, and namespace URIs do not.
> 
> Last year, while Namespaces were being designed, some people argued
> (quite intelligently, as it turns out) that the REC should explicitly
> state that there is nothing to be retrieved at the other end of a
> Namespace URI; unfortunately, RDF does confuse the Namespace URI
> (which cannot be retrieved) with the schema (which can be), so the
> waters get unnecessarily muddy.

Okay, this all makes sense; if we're treating our URL as a URL, then we know
that there is only one document at that location, and if we're treating our
URL as a URI, then we know that our namespace is unique.

BUT, even given this, this still seems like a hack to me.  If HTTP is the
"hypertext transfer protocol", then shouldn't it be used to transfer
hypertext?  The example above isn't <em>quite</em> the same, because there
is no protocol attached to the beginning of those numbers.  (e.g.,
VISA://16137224697)  It's kind of like saying that because your VISA number
is unique we could use it to identify you (assuming that you are a
"resource"; yes, we <em>could</em> start calling you VISA://16137224697, but
that's not really what the VISA:// protocol is for.  OTOH, using
SIN://16137224697 makes a bit more sense, because a Social Insurance Number
is designed specifically to uniquely identify someone.

Just like HTTP is designed to retrieve documents, and some other protocol
could be used for namespaces.  (I am, perhaps, completely misusing the word
"protocol", but I hope my meaning is getting through...  :-)

David Hunter
david.hunter@m...
MediaServ Information Architects
http://www.MediaServ.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...)



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.