xml-dev - Re: Comments on Section 2.6 of XML-Namespaces

["Rick Jelliffe" <ricko@allette.com.au>]

-----Original Message-----
From: Andrew n marshall <amarshal@usc.edu>

> While you point out that this there is no grammatical or conceptual errors
> here since all HTML elements define the class attribute, there is no
> guarantee from the DTD that they mean the same thing in use.  While it
> happens that they do mean the same thing in HTML, allowing this namespace
> syntax fails to resolve the ambiguity on mean in other possible XML
> applications.

 I think it is important to know that the namespace mechanism does not
attempt to solve all problems with sticking names into schemas.
All it does is bundle names with a comon prefix into a bag with a name
(the "ns" attribute") and then point to some other resource which
may contain some interesting information about the schema.

Most elements and attributes belong to multiple schemas. This is
both because no one schema language is good enough to define
all the requirements that any single type has, and because of the
symphonic, interrelated nature of the use of elements in documents.

So the namespace mechanism does not attempt to provide a general
solution to all these problems. If you are interested in such a thing, then
the HyTime architectural forms mechanism may be of interest to you.
(See http://www.ornl.gov/sgml/wg8/docs/n1920/html/toc.html )
It is a far more general solution to a fairly similar problem. The namespace
mechanism as proposed is a minimal and modest thing, just enough to
allow RDF and some other applications to progress, and to allow
debate and exploration of the particular issues.

As for as your particular example goes, there is "no guarantee from the DTD
that they mean the same thing" because there is no mechanisms built
into raw XML DTDs to provide such a guarantee: in fact this is why
namespaces are needed--to make it clear that an attribute in one
element type is kin to another.

And in any case, in your particular case of hrefs, the XLink draft provides
an attribute remapping feature. So an href element

* is attached to its element type in the Instance (& DTD)

* is bound to a namespace by its prefix and the namespace PI

* may be remapped to a different name by the Xlink xml:attribute attribute

* may have additional schemas and semantics added using the
Architectural Forms Deinition Rquirements AFDR mechanism
(See http://www.ornl.gov/sgml/wg8/docs/n1920/html/clause-A.3.html )
which uses fixed attributes on the DTD in particular.  (Architecture =
schema)

<!-- example of an attlist with all these 4 forms of together -->
<!ATTLIST x
        xml:link            CDATA     #FIXED     "simple"
        xml:attribute     CDATA     #FIXED     "href my:href"
        my:href             CDATA     #REQUIRED
        ArcNames       CDATA    #FIXED      "your-schema my:href your:href "
>

In this example (dashed off, apologies if there is an error) the my:href
attribute
will have some syntax or semantics determined by its element type "x", some
from
its namespace "my", some from its role as a simple XLink, and some from
it being an alias to ""your:href" in the schema "your-schema".   This should
not be confusing--it shows that XML offers a great degree of richness, and
that there are several ways of skinning the same cat.

In the usual case, the connection with the namespace of the element type
is enough. In some general cases, like XLink, there will need to be both
a general mechanism for specifying the semantics of an attribute (.e.g
xml:attribute)
and a way to specialize this in an element-type independent way (e.g.
namespaces).
And finally, some particularly rich kinds of data may need to have multiple
schemas specified...the HyTime AFDR mechanism is there for this.

This gives a nice hierarchy of techniques to use from simplest to most
complex.

Rick Jelliffe



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)