RE: Q to implementers: Resource identifiers - XML Names and/or(concatenated) URIs? (was RE: rdfs.isDefinedBy...)

Thanks for your response, Patrick. My response appears inline:

> I'm responsible for pushing the "truth" that *namespace prefixes*
> (not qnames) are punctuation, which they are.

Apologies if I misquoted you or anyone back there... I was trying to whip up
a quick example and didn't hunt down an exact reference. My intent was more
to illustrate that many in the RDF community seem to claim independence from
the Namespaces in XML specification (for dependency reasons we all
understand) yet still use and abuse selected parts of that very
specification, and I find this more disrespectful and disconcerting (because
of the confusion it often seems to cause) than not using the specification
at all.

> Qnames are in direct competition with URIs as a global naming
> scheme. XML is inherently incompatable with the Web architecture
> in this regard. A QName is not a URI, and there is no formal
> specification for how they might map to one another which is
> standardized for all web applications (XML Schema folks, please
> note that final qualification, eh? ;-)

Re: the above and something you said in your other response on this thread:
"I do not see any reliable, robust method of getting to the original qname
from a resource URI.":

Agreed, and as such our application currently does not assume any form of
automatic mapping (recommended concat/split or otherwise) between QNames and
straight URIs during (de)serialization. It does, however, internally allow
you to use either a namespace + local identifier or just a full identifier
and provides "helper" routines if such concat/split is desired.

This available choice in behaviour does cause one problem scenario (of which
I'm aware) and it is the exact reason I started this thread: The application
could, in certain "misuse" scenarios, perceive as distinct two resources
(one identified with a full URI, concatenated* or originally opaque, the
other identified with a namespace + local identifier, whether split* or
provided originally in that form) which, if using the WG recommended
processes, when expressed in a single model/graph should map to a single
resource. (* - as per WG recommended processes or otherwise)

However, since our (de)serialization mechanisms could be made to behave as
per whatever identifier "translation" process is necessary we can ensure
correct external behaviour in integration scenarios while the internals of
the system can be left to operate consistently. There is some remaining room
for the above-described problem when working with our application
programmatically in extension scenarios, but since we have pretty good
control over who touches the system from this angle (basically ourselves and
a group of third party developers involved in active relationships) we can
ensure its consistent use. At the end of the day, the system should behave
consistently both internally and externally, that is, as long as we haven't
missed a scenario not covered by the points I've made here.

In case such a scenario exists, and to support the existing
(de)serialization scenarios, I already have several general solutions in
mind, and wished to hear how other implementers have addressed the various
inter-related issues in this area in order to help determine whether or not
we would need to implement such a solution deeper within the system,
especially considering that, as you, myself, and others before us have all
pointed out, the recommended process for automated mapping doesn't produce
correct results.

Regardless of my desire to avoid implementing one, such a solution would
likely be based on the fact that if we are expected to believe that the
recommended concatenation and splitting processes are "good enough" then
they can be employed _in either direction_ without negative effect (or at
least no more negative an effect than already achieved through the "normal"
usage of such processes) in order to feed a system in which the concept of a
namespace is a first-class entity. In essence, splitting on _input_ when
needed, concatenating on _output_ if needed. Of course, I have not and would
prefer to not implement any such solution since the recommended processes
are not "good enough" to use during (de)serialization and integration, let
alone to be unleashed to create corresponding inconsistencies and unexpected
behaviour _inside_ my system! :)

> The fact that a namespace prefix is a URI, and that URI *might*
> resolve to something has nothing whatsoever to do with the functional
> purpose of a namespace -- which is simply to serve as globally
> unique and consistent punctuation for partitioning local names
> into disjunct collections. Period. That's all namespaces do.

Fully agreed with respect to "that's all namespaces do", though I think we
would all be better served by thinking less often in terms of the
punctuation (:) and more often in terms of the resulting logical
partitioning - the "compound key" as it were. As for those who read more
into namespaces, the whole "let's assume we can retrieve the RDF schema from
the namespace URI" thing is frankly quite frightening. I could list a whole
gamut of other little things that are also quite frightening, but I'm not
sure I want to open Pandora's box so early into my "un-lurking" on these
mailing lists. :D

> A QName bears semantics. A namespace prefix does not.

If you meant "namespace prefix" than it certainly does bear semantics,
though only in the context of Namespaces in XML -compliant XML processing,
and certainly not within the context of RDF itself (even in our
implementation thereof).

If you meant "namespace" then it also does, but only in terms of
partitioning and not in terms of schema retrieval or any other such
mutation.

> > Okay, raise your hand if I just offended you. :)
>
> No offense here ;-)

Much appreciated. :)

Jeremy

Received on Friday, 7 June 2002 11:41:24 UTC