At 23:06 9/6/97 -0700, Jon Bosak wrote:
>4...., it is necessary to be able
>to get more than one category of "meaning" about a given element.
>These different semantic axes may have to come from different places.
>For example, in <birthday>19850527</birthday> it may be necessary to
>point to one specification in order to indicate that the content
>refers to someone's date of birth and to a different specification to
>indicate that content happens in this case to be in ISO format. This
>is multiple inheritance, but of a kind that can apparently be dealt
>with simply by providing the ability to attach multiple namespace
>identifiers to a given element.
I'm not convinced that inheritance of name-space is the correct way to cope
with the fact that this element's contents are in ISO 8601 format. This
information has nothing to do with the name space of the birthday element,
or whose birthday it is. It is simply a notation used to encode the data,
and should be noted as such in some notation or encoding attribute.
What is really important is that this element needs some behaviour
associated with it before it can be presented to real users, and that this
behaviour is dependent on the environment of the user (which language he
speaks, what date convertors are available on the local operating
system,....). What you need is a namespace that redirects the notation name
to a local processor. This is what SGML notation declarations seek to do.
The question that we should really be asking ourselves is "What we need
namespaces for?". If it is simply to attach processing methods to elements
then we need a general purpose behaviour naming property that can be
indirected to local processes. If you don't want to use NOTATION for what it
is designed for then you need something along the lines of:
<!BEHAVIOUR ISO8601 MODULE-NAME date.class >
....
<birthday behaviour="ISO8601">12850527</birthday>
Such behaviourism is not an extension of the explicit behaviourism that
forms part of style sheet specifications, as some have suggested, because
the indirection must be handled at system/user level and not at the
generating system level. (Though I would like to be able to change my mind
on this if DSSSL-O could be extended to provide a good, and simple,
mechanism for local overriding of formatting behaviour!)
I have advocated before (more times than I like to remember) the need for
being able to attach behaviour to any XML element, not just links. We cannot
process XML forms without a behaviour attribute, so any EDI application of
XML must add behaviour to the specification. It would be nice if this could
be generalized. I suspect that this is really what many of the people
talking about the need for namespaces really want.
Martin Bryan
----
Martin Bryan, The SGML Centre, Churchdown, Glos. GL3 2PU, UK
Phone/Fax: +44 1452 714029 WWW home page: http://www.sgml.u-net.com/