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

Thoughts on namespaces

From: Christopher R. Maden <crm@eps.inso.com>
Date: Thu, 22 May 1997 16:30:43 GMT
Message-Id: <199705221630.QAA02648@phaser.EBT.COM>
To: w3c-sgml-wg@w3.org
I think that the namespaces can be accomplished with one change to the
assumed XML as SGML declaration and an application convention.

First, I believe the primary goal of namespaces is to allow borrowing
of established semantics - I want to use TEI's <xref>, HTML's <a>, and
the FAQ DTD's <q> and <a>.  That means two things must be

(1) subclassing of GIs to prevent clashes, as in HTML's <a> and the
    FAQ <a> above; and
(2) association of semantics, if known by the application, with the
    new GIs.

The first goal is actually the easy one; once a subclassing convention
(such as namespace::orig-GI) has been decided on, it can simply be
used in the actual or virtual DTD:

<!DOCTYPE mymess [
<!ELEMENT mymess    (html::p | faq::q | faq::a)*>
<!ELEMENT html::p   (#PCDATA | html::a | tei::xref)*>
<!ELEMENT faq::q    (#PCDATA | html::a | tei::xref)*>
<!ELEMENT faq::a    (#PCDATA | html::a | tei::xref)*>
<!ELEMENT html::a   (#PCDATA)>
<!ELEMENT tei::xref (#PCDATA)>

Element names of this sort can be arbitrarily constructed, but they
are not meaningful.  One might associate the incorporated schema with
their identifiers thus:

<?XML-schema source="-//W3C//DTD HTML 3.2 Final//EN" id="html"?>

If formal public identifiers are not used, some other presumably
unique identifier can be used.  It need not be a URL for a scheme;
what would that URL contain?  A DTD is not going to convey the proper
*semantics*, which is what is desired here.  I propose that the
application, if it supports schema, look for this identifier in its
list of known schema.  If no match is found, the application will rely
on the stylesheet for behavior, just as it would if the author had
created his own scheme.

In the example of incorporating HTML semantics, if the identifier were
known to the application, it would turn a particular <applet> element
into a little dancing elephant, but otherwise it would do whatever the
XML stylesheet said to.

With an implied DTD, the processing instructions can still be present
at the top of the document instance.  I do NOT believe that they
should be permitted to appear within any element to set up a new
namespace; that would create a dependency on parsing backwards for
context, which requiring the PIs at the top does not.

This would not put undue burden on authors, I think.  To allow
processing by non-schema-supporting applications, they should provide
stylesheets, but if they are borrowing the semantics from known DTDs,
they can presumably borrow chunks of (element ) statements from
associated stylesheets.

Thoughts?  Counterproposals?

Christopher R. Maden                  One Richmond Square
DynaText SIT Technical Support        Providence, RI 02906 USA
Inso Corporation                      +1.401.421.9550 (voice)
Electronic Publishing Solutions       +1.401.521.2030 (facsimile)
Received on Thursday, 22 May 1997 12:47:31 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 21:25:26 UTC