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

 


Help: OASIS Mailing Lists Help | MarkMail Help

 


 

   Re: URI concerns continue

[ Lists Home | Date Index | Thread Index ]
  • From: Eric van der Vlist <vdv@dyomedea.com>
  • To: XML-Dev Mailing list <xml-dev@xml.org>
  • Date: Tue, 11 Jul 2000 16:33:02 +0200

Eric Bohlman wrote:
> 
> I think that one of the problems here is that we've got a "terminological
> hijack" going on, similar to the one I mentioned a while back (though I'm
> not sure whether on xml-dev, xml-uri, or both) involving the American and
> British uses of the phrase "learning disabilities."  In the decade or so
> that URIs (almost entirely in the form of URLs) have been in use, they've
> been the identifiers (in reality, addresses) of *concrete* things, namely
> entity bodies, and a generation of developers and users have built a
> mental model of URIs based on this use.
> 
> But it's plain that the W3C's vision of URIs is heavily based on using
> them to name *abstractions*, and that a good part of the URI community is
> having a hard time fitting this into their mental models.  I'm starting to
> wonder whether overloading the notion of a URI (particularly in the URL
> form) to encompass both addressing sequences of bits and identifying
> abstract statements in a form of higher-order-logic is really a good idea.
> Maybe the distinction between floor waxes and dessert toppings actually
> serves a useful purpose in practice if not in theory and shouldn't be
> blurred solely in the name of mathematical elegance.  Imagine a
> programming language in which all arithmetic had to be done in terms of
> set-theoretic primitives.  It would be extremely elegant, but not very
> useful.
> 
> In particular, I have a really hard time with the use of a
> retrieval-protocol component (like http or ftp) in something that's
> supposed to name an abstraction rather than specify how to retrieve
> something concrete.  I'd be a lot happier if we were to reserve URLs for
> naming concrete things and keep the names of abstract things to a subset
> of URNs or to some sort of public identifier.  To do otherwise is, IMHO,
> to invite a great deal of map-territory confusion, and to leave people
> wondering whether particular maps actually correspond to any territory.

This is a good explanation of why the namespace URI discussion has been
so full of rebounds and a sensible suggestion.

My take on this is that, especially because we are building on moving
and abstract grounds, great care should be taken to describe in great
detail how these URI references should be processed and to answer to the
basic questions :

 - are relative references allowed ?
 - how should they be processed ?
 - when are 2 references considered as equal ?

before it's too late like it has been the case for namespaces URIs.

It could be done "individually" in each recommendation (it's currently
lacking in the XLink one) or (better if achievable) in a common document
as proposed by Simon.

And, yes, it's because we are touching to abstract concepts whose
meaning is subjective that we need to be more concrete in our
description.

Eric
-- 
------------------------------------------------------------------------
Eric van der Vlist       Dyomedea                    http://dyomedea.com
http://xmlfr.org         http://4xt.org              http://ducotede.com
------------------------------------------------------------------------




 

News | XML in Industry | Calendar | XML Registry
Marketplace | Resources | MyXML.org | Sponsors | Privacy Statement

Copyright 2001 XML.org. This site is hosted by OASIS