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


Help: OASIS Mailing Lists Help | MarkMail Help



   RE: [xml-dev] URIs harmful (was RE: [xml-dev] Article: Keeping pa ce wi

[ Lists Home | Date Index | Thread Index ]

It means the author decides and the resolver will do with 
the string what it always does with a string with that 
precise syntax.   The string is just a string until 
given a context.  The problem is that the context of 
the namespace declaration is available to the resolution 
engine.  It is the syntax byte for byte identical 
construction that enables that.  A URI with HTTP 
is a URL.  No difference; no difference.

There are standard ways to resolve FPIs.  Catalogs.  
There is nothing mysterious or funky about that. 
What one ends up with is a chained set of disambiguating 
resources.  Integrated Open Hypermedia by Bibliographic 
reference.  Citing the chain is the key to creating 
the context.  Thus, RDDL and Catalogs or ERROR and 
of these, the last should be deprecated.


-----Original Message-----
From: Uche Ogbuji [mailto:uche.ogbuji@fourthought.com]

> No.  Unless you build a means and tell the parser to invoke 
> it, an FPI is a dumb string.

My point is that if FPIs were used for the sorts of things that XML 
technologies use URI for, that there would be a standard means for lookup and 
"dereferencing".  It would just come about naturally.

Same thing if specs mandated URNs rather than URIs.  There would have been 
systems for resolving URNs in place by now.

Nothing that is treated as a global identifier remains a "dumb string" for 
long.  Nothing.

> A URzed is always dereferenceable.  If we accept that, then what 
> we call it and the semantic issues go away. 

Wow.  That's confidence.  For my part, I think there will be plenty of 
semantic issues left even if one were to declare that a URI is "always 

BTW, I personally don't have a problem with such a declaration.  It's just 
that I'm not entirely sure what it means.


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

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