W3C home > Mailing lists > Public > w3c-sgml-wg@w3.org > June 1997

Re: Update on namespaces

From: David G. Durand <dgd@cs.bu.edu>
Date: Thu, 12 Jun 1997 13:35:03 -0500
Message-Id: <v03007804afc5f0f1e1c4@[]>
To: w3c-sgml-wg@w3.org
At 1:06 AM -0500 6/10/97, Jon Bosak wrote:

>1. One workable way to universally disambiguate the names of elements
>is to associate them somehow with specific URIs.  Not everyone agrees
>that this is the best way -- some of us would prefer a mechanism like
>the SGML formal public identifier -- but there seems to be a general
>acknowledgement that it will work.
Since URIs include URNs, FPIs will be included.

>2. While some namespaces may be specified in a machine-interpretable
>form, other namespaces (and perhaps a certain component of all
>namespaces) will be in a form that cannot be interpreted by a machine.

Sounds like semantics to me.

>3. There seemed to be general agreement that validatable structural
>information is not among the things that minimally need to be conveyed
>by a namespace identifier.  For example, it might be necessary to
>convey the information that an <author> element is intended to contain
>the name of a human or organization that created a work, and it might
>be necessary to convey the fact that its data type is STRING, but it
>is not necessary in meeting the PICS-NG requirements that the <author>
>element specify either an inherited content model from some DTD or
>that it conform to a content model from some DTD.  In other words, as
>far as we can tell at the moment, the namespace problem does not
>require a solution that involves DTDs.  This does not mean that such a
>solution would not be useful, but it does seem to imply that it can
>wait for the SGML revision.

So, we throw out the notion of validation? sounds liek a high price to pay,
particularly since all we're doing is indentifying an element with some
persistemnt external identifier so that we can do some kind of specialized
processing. Sounds like an architecture to me.

>4. As indicated in the example just given, 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.

Or multiple architecture attributes -- same effect, but we don't have to
change the specification by one jot or tittle, just document the convention
for those who care (e.g. the PICS folx).

>5. There is hope that the additions to xml-lang needed in the short
>term can be reasonably small, just enough to enable the solution of
>the more general problem later on.

The null addition is the smallest one possible, and seems to do the job.

  -- David

David Durand              dgd@cs.bu.edu  \  david@dynamicDiagrams.com
Boston University Computer Science        \  Sr. Analyst
http://www.cs.bu.edu/students/grads/dgd/   \  Dynamic Diagrams
--------------------------------------------\  http://dynamicDiagrams.com/
MAPA: mapping for the WWW                    \__________________________
Received on Thursday, 12 June 1997 13:32:22 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 20:25:10 UTC