- From: Sam Hunting <sam_hunting@yahoo.com>
- Date: Mon, 5 Jun 2000 20:06:01 -0700 (PDT)
- To: michaelm@netsol.com, David Carlisle <david@dcarlisle.demon.co.uk>
- Cc: xml-uri@w3.org
Taking off from what Michael Mealling and David Carlisle have written--
Here is a sketch for amending the Namespaces specification:
<clause>
<production>
[19] NSresolution ::=
prefix ':resolution' s 'none | relative | absolute' s "'none'"
</production>
<para>
Where the namespace denoted by prefix has a resolution attribute of
'relative', either relative or absolute URIs can appear as the value of
that namespace declaration. Where that namespace's resolution attribute
is 'absolute', it is a non-recoverable namespace error for any URI
other than an absolute URI to appear as the value of that namespace
declaration.
<note>
"non-recoverable" = "Draconian"
</note>
<note>
It is never a namespace error for any reference, either absolute or
relative, to fail.
</note>
<note>
A namespace where no resolution attribute has been declared has an
implicit resolution strategy of 'none'.
</note>
<note>
Only those namespaces whose resolution is 'none', implicitly as in
the note above, or explicitly, conform to the Namespaces 1.0
Recommendation.
</note>
</clause>
Example:
<x xmlns:n1="http://www.w3.org" xmlns="http://www.w3.org" >
<good a="1"
n1:a="2"
n1:resolution="none"/>
</x>
Just a sketch, and I hold no brief whatever for the syntax. ([19] is
really just an instance of [18].)
The important thing to me is the principle.
It is apparent that no consensus on a single namespace resolution
strategy is forthcoming. Therefore, let people make the choice that is
best for them, have them be explicit about the choice, and set a
reasonable default (in this case, the only un-tendentious
interpretation of the original namespace specification).
> > No. Namespaces are not broken, and don't need fixing.
If they are broken, it is not for the reasons discussed on this thread.
> > So the following facts about namespaces should remain true after
> > any re-issue of the namespace spec.
> >
> > * Namespaces are not "defined" they are just used (declared) in
> > document instances.
>
> Yep...
Still true with proposed production [19].
> > * The namespace name is a URI reference (or URI or URI + fragment
> id
> > if one of the possible, but unfortunate, changes is made).
> > The existence or not of a resource at the URI used as the
> namespace
> > name is immaterial to all namespace processing. (Although some
> > process following the xml namespace parse may of course
> dereference
> > the name as a URI if it cares to do so)
>
> Yep...
Still true with proposed production [19].
> > <foobar xmlns="http://www.w3.org/1999/Markup/XHTML"/>
> > is a well formed XML document that conforms to the namespace
> spec.
Still true with proposed production [19].
> > Schema validation sits above namespace parsing, it is not an
> > integral part of it.
Still possible with proposed production [19].
> > All namespaces have identical structure (which is why they don't
> > need to be defined anywhere)
No longer true, but since the community can't achieve consensus on a
single semantic, it seems reasonable to surrendur on this point. In my
view, it's more important that no documents break than that all
namespaces have identical structure.
> > The existence of a schema (or in the case of xhtml, several
> > schema)
> > using elements from the namespace does not alter the namespace at
> all.
>
> Yep...
Still true with proposed production [19].
> > * Users can choose a unique namespace name for namespaces they want
> to
> > use without requiring a central registry, or owning an internet
> > domain name.
Still true with proposed production [19].
> Besides, domain-names violate the persistence requirement. But yes,
> you want decentralized assignment...
>
> > * Exiting namespace names which are absolute URI possibly with
> > fragment id remain valid. (and don't require any particular
> > format of file to be placed at the URI)
Still true with proposed production [19].
> > * Namespace parsing never requires the retrieval of any external
> > resource.
>
> Yep...
True with the default semantic of proposed production [19].
> Agreed with all of this. The issue with those of us who want to
> build something on top of this is that the XML namespace 'name'
> shouldn't prevent someone from attempting to resolve it.
Possible with either the relative or absolute resolution strategy.
> Allowing
> a relative URI without a BASE is an error and thus makes it so that
> the namespace 'name' prevents someone from attempting to resolve it.
Hope this helps out....
S.
=====
<? "To imagine a language is to imagine a form of life."
-- Ludwig Wittgenstein, Philosophical Investigations ?>
__________________________________________________
Do You Yahoo!?
Yahoo! Photos -- now, 100 FREE prints!
http://photos.yahoo.com
Received on Monday, 5 June 2000 23:06:40 UTC