Namespace questions

[james anderson]

i'm afraid i'm going to repeat myself, but ...

Ron Bourret wrote:
> 
> 1) Can I have multiple prefixes in the same file that point to the same
> namespace?  The namespace spec doesn't appear to prohibit this.

from an implementer's point of view, "yes". different prefixes within the same
file should be able to denote the same region in the namespace.
since all uses of a prefix are in single physical entity are "lexically
apparent" this shouldn't lead to problems.
since the namespace pi's can contain literals only, why would one need to do it?

> 
> 2) How do namespaces and XLinks work together?  For example, suppose I link to
> the <Foo> element in another file.
> 
> a) If the <Foo> element is prefixed (that is, it is really <Bar:Foo>) does my
> pointer need to know this?

the short answer is: "yes".

all name tokens (even those which don't appear so in serialized form) are
effectively qualified. their internal representation needs to be as well,
since in use the dynamic context from the encoding is no longer present. this
is necessary in order that the proper namespace binding can be communicated to
whatever process resolves the reference. your pointer may, however not have
appeared with "Bar:Foo" identifiers prior to decoding since the "Bar" implies
a binding which will be in effect when the resolving process decodes, not when
your application decoded.

neither the namespace nor the xpointer wd makes any statement on these matters.
wrt the namespace wd: attribute values (of which xpointers are one kind) don't
fall among the specified productions.
wrt to the xpointer draft: it appears to have been conceived n.s.a. (that's
name-space-agnostic) despite that, all of the productions which involve "Name"
would appear make sense to modify for "QName"'s. which implies that a pointer
should permit qualification. which implies a standard means should be
available to en/decode elements of an xpointer which comprise names. this
service should be offered by the en/decoding layer.  until (read "if") it is
possible to place type constraints on attributes your application will have to
determine on its own in which cases it is appropriate to request this service.

whether the serialized form of the xpointer contained "Bar:Foo" id's would
depend on where it came from. if it was in the same document as the link's
target resource, then the prefixes will likely agree (modulo the answer to
your first question). if it's from somewhere else, the prefixes may differ.
the "universal name" remains the same.

when an xpointer is decoded or serialized, the dynamic element scope could
carry over to attribute content when it comes to interning and serializing
symbols - including those from xpointers. which would cause (some) serialized
names in an xpointer to appear unqualified. that does not, however address the
general case, as the identifier in the refering element may (likely) reside in
a different namespace region than the target resource and its attributes. for
that reason, in order to generate robust locators, the serialized form may
well contain qualified names.

more specifically,
1. the encoding layer has to be aware of the dynamic prefix bindings in effect
at the point where an element is serialized and prefix all name tokens as
appropriate - including attribute content where necesssary
2. an http request containing such a request will either need to include
prefix bindings in the header or comprise an xml document.

> 
> b) When I get the <Foo> element back as a result of resolving the link, do I get
> <Foo> or <Bar:Foo>?  And if I get <Bar:Foo>, do I also get a namespace PI
> telling me about the Bar prefix?

where the reference is inter-document, in general you cannot require that you
get a <Bar:Foo>. you should well expect that the encoding may have contained a
<Baz:Foo>, in which case your decoder should also have gotten a <?namespace
ns="the ns region which Bar was bound to" prefix="Baz" ?> and should be
presenting you with the same symbol as "Bar:Foo" named when it was interned.

this is, in any event, just a discussion of "appearances".
if your encoding layer is proper, your application shouldn't be concerned with
the "Bar" or the "Baz".
but then, i'm repeating myself again...

xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev at ic.ac.uk
Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/
To (un)subscribe, mailto:majordomo at ic.ac.uk the following message;
(un)subscribe xml-dev
To subscribe to the digests, mailto:majordomo at ic.ac.uk the following message;
subscribe xml-dev-digest
List coordinator, Henry Rzepa (mailto:rzepa at ic.ac.uk)