[
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.
len
-----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
dereferenceable".
BTW, I personally don't have a problem with such a declaration. It's just
that I'm not entirely sure what it means.
|
