namespaces for name attribute values?

David Brownell db at Eng.Sun.COM
Sat Oct 3 18:53:59 BST 1998


Eric Hellman wrote:
> 
> Well, a versioned URL for Dublin Core would be nice, but I was thinking of
> something different.

I was just going by your example.


> I'm suggesting that it may be useful to make a namespace declaration simply
> to declare semantics of something that isn't in a DTD, namely the attribute
> values.

And I wouldn't disagree, but then you still need to get into the
versioning issues to some degree.  The URI associated with a
namespace has no fundamental association with the semantics you're
trying to declare!

Unless the folk managing the name contexts associated with that URI
have agreed to support associating those semantics, you (and any
other folk who use that URI that way) may have problems due to
changes beyond your control.


> Suppose you want an attribute value to contain a MIME type. Right now, you
> can either declare the attribute as CDATA or you can enumerate the possible
> MIME types.
> 
> ...
> 
> If you declare a default xmlns (with an appropriate URL) for an element, an
> XML authoring application could know where information about appropriate
> attribute values might be found, and may avoid forcing authors to plow
> through your DTD.

In this case you want that code to manage versioning (e.g. of some
list of approved MIME types) externally.  The versioning problem is
still there, but the semantics of such an attribute ("mime:type")
are set up to vary over at least time.

Most systems would consult a local table rather than creating a new
globally accessible database of legal MIME types.  So even if the tools
authors use _could_ always access that database (no network failures),
the "appropriate" values will have different meanings on the same day
all over the world.


In summary:  all namespaces (ever) do is provide a layer of indirection.
Their meanings change over at least time.  When you use namespaces you
need to consider what that change will do to your applications.

- Dave


> It's clear that this was not an intended use of namespaces, but as far as I
> can see, it won't do any harm.
> 
> Eric
> 
> David Brownell wrote:
> >Andrew Layman wrote:
> >>
> >> Perhaps you do not really have a problem.  What I'm thinking is that if you
> >> wrote something similar to the example you showed,
> >>
> >> <foo xmlns:DC="http://purl.org/metadata/dublin_core">
> >>    <DC:Creator>Eric Hellman</DC:Creator>
> >> </foo>
> >>
> >> then the meaning of DC:Creator is not affected by any additions made to
> >> Dublin Core.  Your DTD remains valid, simply not as extensive as the
> >> (expanded) Dublin Core.
> >
> >For Dublin Core, perhaps -- but not in general.  Suppose
> >the addition were to modify the content model for something
> >like the "Creator" element referred to above?  Validity isn't
> >automatically preserved in such cases.
> >
> >Namespaces need versioning.  URIs can easily include date
> >codes like "02Nov1997"; W3C itself uses such a scheme, as
> >you can see by looking at versions of the namespace spec.
> >
> >I'd expect the definers of such namespaces to identify
> >their versioning policy, including publishing URLs which
> >apply to each iteration.  A "most current" URL can be of
> >use in some cases (loose coupling), but not usually in
> >systems that depend on precise semantics and hence need
> >updates to support new features.
> >
> >
> >So my response to Eric is to get a versioned URL for the
> >Dublin Core, and to use that!  ;-)
> >
> >- - Dave
> Eric Hellman
> Openly Informatics, Inc.
> http://www.openly.com/           Tools for 21st Century Scholarly Publishing

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)




More information about the Xml-dev mailing list