OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.


Help: OASIS Mailing Lists Help | MarkMail Help



   Proposal for src files

[ Lists Home | Date Index | Thread Index ]
  • From: Peter Murray-Rust <peter@ursus.demon.co.uk>
  • To: "xml-dev@ic.ac.uk" <xml-dev@ic.ac.uk>
  • Date: Wed, 01 Apr 1998 09:22:54

I am very pleased to see the namespace draft being discussed here because I
think it has important bearing on implementation. I have been privileged to
be on the XML-SIG and - without revealing confidentiality - there was a lot
of closely argued discussion and this is clearly a tough problem [?tougher
than some people initially expected?]. 

The clarifications given here have been spot-on - the provision is
primarily syntactic, providing the identification of components of a name,
and the namespace(s) referred to. The distinction between identification of
the namespace (ns) and the details of it (src) is very welcome.

Specific comment:
The following example has been used in the namespaces draft:
<Item T.Heat:Temp='5500'/>
and suggests some special role for the '.' in the attribute name. There
appears to be a widespread practice among SGML authors of using '.' as a
means of indicating structure in names. There is no syntactic significance
for the '.' in XML and I very much hope that there is no 'implied
semantics' given to it. I believe the only reason for it is human
readability, and it could be seen as misleading in the current discussion.
As far as namespaces are concerned, processing software should treat
T.Temp: and Plugh: on equal terms.

Clearly anyone wishing to implement namespaces *now* has a problem in that
there are no agreed semantics. Since namespaces are (in large part) about
interoperability between different document designers (who are probably not
in communication) it seems likely that uncoordinated approaches could give
rise to confusion. By concern - and I'm sure it's shared by many - is that
we get embroiled in 'namespace soup'. 

What the proposal *does* give us is the ability to find out *who* is
responsible for a given tag. In principle, therefore, we can refer to that
tagger's description of its semantics. The problem is the lack of standards
for semantics (e.g. we don't know what is in the src file).

It is clear that some people (e.g. RDF) will develop a de facto approach to
the semantics of namespaces. I suspect that in the first instance most of
these will lead to documents which cannot be validated against a DTD under
XML 1.0 (excepting the ANY content spec). This is my own position - for
reasons mentioned on XML-L, CML documents are not constructed to be

Although having experimented with namespaces for some time and found them
extremely useful, I don't have any simple answers to the problem. If there
are any steps that we can take on XML-DEV to solve *part* of the problem,
that could be very useful. Are there any operations which are common to all
namespace processing? Is it useful to codify the de facto solutions that
people provide so that - at least - we could identify the approach that an
author uses? For those of us developing 'src' files is there a useful way
of identifying the contents? possibly even standardising them?

My own contribution would be to try the following (not to the exclusion of
There seem to be a significant number of people who expect an src document
to be in XML.
I belong to them.
There are a lot of people who wish the schema to represent the validatory
power of an XML DTD. Many wish it *to* be a DTD.

Is it possible to combine these two so that we express a DTD in a standard
XML notation? Many of us do this already, but I suspect that our tagset and
syntax vary. If we could agree on this - and I don't see this as
technically difficult - we could help both communities. Those who wished
more power than a DTD can provide can extend it with further elementTypes
(a la XML-data). Those who wish to use the DTD elementTypes alone can
filter them out very easily and - if required - transform them to DTD syntax.

Clearly this is only one of many things that could reside in an src file,
so some means of identifying it would be required. We should, of course,
create our own namespace for the elements - mapped to xml.org :-)

Given the achievement of creating SAX on this list, we can certainly solve
this one if we wish to.


Peter Murray-Rust, Director Virtual School of Molecular Sciences, domestic
net connection
VSMS http://www.nottingham.ac.uk/vsms, Virtual Hyperglossary

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)


News | XML in Industry | Calendar | XML Registry
Marketplace | Resources | MyXML.org | Sponsors | Privacy Statement

Copyright 2001 XML.org. This site is hosted by OASIS