RE: Update on namespaces

I would endorse what Martin is saying here.

If you combine this with what I proposed in my earlier postings about
the ACTUATE and SHOW attributes not being appropriate as on XML-LINK
elements, it seems to me you would get something like the following:

1)	All elements, whether links or not, can have a BEHAVIOR
attribute
2)	The value of this attribute is the name of a BEHAVIOR which has
been declared through a <!BEHAVIOR ...> declaration
3)	The declaration associates the named BEHAVIOR with a local
processor and/or stylesheet
4)	The stylesheet, if present, uses a syntax which is understood by
the processor.
5)	The styleheet provides rules and/or additional data which
determine how the content of the XML instance is to be handled by the
processor
6)	If the processor is one whose primary purpose is to provide a
formatted display of the content of the XML instance, then the
stylesheet syntax could be something like CSS or DSSSL-O. However, if
the purpose of the processor is to offer other functionality - such as
database storage and manipulation, or the provision of an interface
through which user can interact in complex ways with the content of the
XML document - then the stylesheet syntax would need to be appropriate
to the nature of that task.



	-----Original Message-----
	From:	Martin Bryan [SMTP:mtbryan@sgml.u-net.com]
	Sent:	Tuesday, June 10, 1997 9:21 AM
	To:	w3c-sgml-wg@w3.org
	Subject:	Re: Update on namespaces

	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 07:39:50 UTC