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

Re: SD5 - Namespaces

From: Steven J. DeRose <sjd@eps.inso.com>
Date: Tue, 20 May 1997 15:07:27 -0400
Message-Id: <2.2.32.19970520190727.00b311a0@pop>
To: w3c-sgml-wg@w3.org
At 03:58 PM 05/20/97 GMT, Peter Murray-Rust wrote:


>This allows an author to create their own fully qualified names for GIs,
>thus avoiding tag collision.  How they do this is outside the scope of XML.
>Examples could be CML:MOL or org.w3.MathML:PRODUCT.  If the convention is 
>adopted that the namespace prefix is either the DTD name or a fully qualified
>version the chances of collision are reduced to the chances of DTD names 
>colliding.

I'm not sure aboout this proposal, but I am sure we should not try to
re-define the already common term "fully qualified". It already means the
element
type in the context of its *containing* element types; such as
"BOOK,BDY,CHP,SEC,P".
That is radically different from the sub-typing mechanism under discussion.

In short, "is-a" is not the same relation as "has-part".

>
>It is possible to create one DTD that can be used for both forms (I hope
>that I don't get shot down in flames...).  If we have:

Whether this works depends on what the constraints on subclassing are. Is it
the case that every
subtype of a type must permit all child-sequences that the type permits? Or
is it vice versa? Or must the sets permitted be identical? Or unrelated?
Architectural forms attempt to address this, but only provide the first case
(approximately); and cannot be used to unify processing of
slightly-differing structures, such as deflists with item-pair containers,
versus without. Do we really want to dive into this?

If this subclassing mechanism is purely for people to be able to
interoperate in terms
of browsing, why is it better than HTML "CLASS=", where you leave the GI
alone? That's
certainly simpler, right?

S

Steven J. DeRose, Ph.D., Chief Scientist
Inso Electronic Publishing Solutions
   (formerly EBT)
Received on Tuesday, 20 May 1997 15:10:30 UTC

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