- From: Martin Bryan <mtbryan@sgml.u-net.com>
- Date: Tue, 10 Jun 1997 09:20:32 +0100
- To: w3c-sgml-wg@w3.org
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/
Received on Tuesday, 10 June 1997 04:21:15 UTC