xml-dev - Re: Inheritance and other buzzwords

[james anderson <James.Anderson@mecom.mixx.de>]

hello again,

there were some things in a remark yesterday from Rick Jelliffe and in a note
from Peter Murray-Rust which lead me to doubt that wd-xml-names will work unless
it is extended to more completely specify the semantics of the namespace
declaration pi.

in previous remarks, it has been explained that the wd expressly avoids
specifying a semantics. (andrewl@microsoft.com/RE: Namespaces in XML: 3.1 the
example [2]/Tue, 31 Mar 1998 19:01:05 -0800)
that it says, that the pi has a scope over the document in the prologue of which
it appears does not suffice. this still leaves room to create documents which
have conflicting and incompatible interpretations. while there need be no
requirement that the processor read an external schema (should the SrcDef have
been specified), there should be some indication of what effect the
ns-declaration has on unqualified names in the schema should the schema be read.

there are two possible interpretations to "scope". in one aspect (1) the
alternative is to either (a) affect the region of the articulated namespace into
which unqualified names which appear in the external entity specified by the pi
are mapped or (b) not. in the other aspect (2), the alternative is to either (a)
implicitly specify the region of the articulated namespace into unqualified
names in the same entity in which the pi appears are mapped or (b) not.
the difference in effect can be understood with reference to, mr. jelliffe's
attributed quote. he paraphrases, that articulated namespaces 'allow the RDF
people to say "this element is one of our element types".' i understand this to
assume a semantics which combines 1b and 2a.
the alternative, which would be the attributed assertion that articulated
namespaces 'allow the people to say  "this element is one of the element types
which the RDF people say is theirs" combines 1a and 2b.

this second semantics makes additional remapping unnecessary.

documents created for processors which implement the first semantics would be
incompatible with documents created for processors which support the second
semantics.

as such the wd needs to be expanded to say which of these semantics apply to the
interpretation of external entities in the event that there is a schema at the
other end of the  SrcDef. if not syntactically, then semantically.

in order to avoid the problems noted below and in other places, the
interpretation should best be along the lines of 2b. under that semantic one
would, to take mr. jelliffe's example, promote dtd content such as

<!-- base derived architecture DTD-1 -->
<?xml:namespace prefix="rick" ns="rick-v2-3-1"
src="http://ricks-server/schema/rick-v2-3-1" ?>

and
<!--base derived architecture DTD-2 -->
<?xml:namespace prefix="rick" ns="rick-v2-3-2"
src="http://ricks-server/schema/rick-v2-3-2" ?>

and
<!-- derived derived arcitectural DTD-1-x-DTD-2 -->
<?xml:namespace prefix="rickv1" ns="rick-v2-3-1"
src="http://ricks-server/schema/rick-v2-3-1" ?>
<?xml:namespace prefix="rickv2" ns="rick-v2-3-2"
src="http://ricks-server/schema/rick-v2-3-2" ?>

the key is that the semantic is not (with reference to Jelliffe/Re: Inheritance
and other buzzwords/Fri, 3 Apr 1998 16:00:41 +1000)

    prefix->ns;   then  ns->schema

but

    prefix -> (localPart -> (schema -> definition))

which, in order words, means that, (within the scope of a given ns-declaration)
given the prefix, one can determine a region of the universal namespace, from
which given the local part one can determine an identifier which can be used
within the context of a given schema to name a definition. (nb. that we're
dealing with 3-d namespaces - i.e. the namespace articulation implicit in entity
v/s p-entity v/s element v/s etc,  is ignored here.)

my specific suggestion (above, the semantic called  1a/2b) is,
a. that  unqualified names should be assumed to have the qualifier  presently
bound to their physical entity by a ns-declaration.
b. the standard define how, in the absence of a ns declaration (eg. a dtd
referenced from a document with a doctype only), a ns-enabled processor is to
generate an implicit ns declaration.
c. explicitly qualified names which incorporate the prefix bound by a ns
declaration within an external to the external entity itself should be
considered 'unqualified' for the purpose of item 'a' above.

for reference purposes, here the two remarks:

Rick Jelliffe wrote:

> From: Tim Bray <tbray@textuality.com>
>
> > The current namespace proposal adds one level of indirection to the names
> > we give document components, and includes a technique for ensuring that
> > the names are unique across the universe of the Internet.  That's all!
>
> I think Tim is correct in trying to limit people's perception of what the
> namespace
> proposal does. The basic requirement is, more or less, to have a declaration
> which is as simple as possible, as non-intrusive as possible, and which
> does not require explicit element or attribute declarations,  which will
> allow
> the RDF people to say "this element is one of our element types".
>
> Whether there is, underlying this, some more interesting structure of links
> derived from type names not instances (my belief), or an underlying
> honeycomb of parallel, mutually augmenting schemas (the architectures
> idea) should not be the deciding factor for the namespace proposal, to
> me. I think it is enough that the namespace 1.0 be expressed in a way that
> does not rule out an interpretation using either ot these mechanisms (or
> others) is enough at this stage.
>
> It was not Tim's point, but strictly I think the proposal adds two levels of
> indirection:
>     prefix->ns;   then  ns->schema
> It is because of this indirection that the current proposal does not ensure
> unique
> naming: there is a possibility of an error where two fragments using the
> same
> prefix are combined under the same namespace declaration. This is
> particularly
> an issue of maintenance: where a schema is updated, perhaps to make it have
> a more restrictive content model.
>
> So XML tools which combine fragments with namspaces will have to be able to
> rewrite name prefixes.  If there is
>     <?xml:namespace ns="rick" schema="rick-v2-3-1" ?>
> and
>     <?xml:namespace ns="rick" schema="rick-v2-3-2 ?>
> then the processing tool will have to be smart enough to, for example,
> relabel
> the second PI
>     <?xml:namespace ns="rick-a schema="rick-v2-3-2 ?>
> and all the names which use this must be relabelled too in the instance.

Peter Murray-Rust wrote:

> [... discussion of the problems inherent in getting along without articulated
> namespaces deleted ...]
>
> My problem only comes when I encounter the Concrete Materials Laboratory
> who also use CML as their prefix. If I want to mix existing document from
> CML and CML I have to edit one set. Tedious. But we do this sort of thing
> every day for other reasons (how many of you have run automatic edits
> through documents when companies' names change, etc.). No big deal.




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