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

Re: Update on namespaces

From: Matthew Fuchs <matt@wdi.disney.com>
Date: Fri, 27 Jun 1997 10:02:12 -0700
Message-Id: <9706271002.ZM16286@scrumpox.rd.wdi.disney.com>
To: w3c-sgml-wg@w3.org
On Jun 27,  8:48am, Peter Murray-Rust wrote:
> Subject: Re: Update on namespaces
> In message <199706270551.PAA30543@jawa.chilli.net.au> ricko@allette.com.au
writes:
> >
> > > From: Andrew Layman <andrewl@microsoft.com>
> >
> > > Namespaces does not mean that suddenly any element is valid anywhere.
> > >
> > > I absolutely am not suggesting that the use of namespace means that
> > > every element suddenly has an implicit content model of "ANY".
> > ...
> > > That is, far from defeating validation, namespaces permit use of
> > > multiple, merged schemata while retaining validation.
> [...]
> > 4) An SGML content model should allow a #OTHER keyword:  ANY is too
> > fixed,
> > and fully declared content models are too restrictive. E.g.
> >
> > <!ELEMENT html ( head, (body | frameset | layer | #OTHER ), tail ) >
> >
> > where #OTHER means you can only use an element from some other
> > namespace.
>
> Both AndrewL and RickJ have proposed namespace philosophies which should be
> supported.  Andrew's might be examplified by (say) a DTD for the J. Physical
> Chemistry (a real journal), which might wish to publish in XML.  It could
> construct its own DTD based (say) on X-HTML, with precise contexts in which
> MathML and CML can be imported.  This may be workable with a very static
> editorial policy where the style was frozen for some years.  The problem  is
> that
> (a) it can be difficult to identify all the places where merged content
> is allowed (e.g. equations (math or chem) in tables, citations, etc.)
> (b) if a new mergeable DTD becomes important, it's extremely difficult to
> edit the DTD to include it.  You start running into n-squared numbers of
> interactions.  And, since CML may very well include (or interoperate with)
> MathML, you may have unforeseen second-order problems.
>
> Rick's position would seem to be the only way of creating a valitable
approach
> for a more general journal like Science or Nature, which range from Astronomy
> to Archaeology.  (At present CML get rounds it by having a single container -
> XLIST - which has a content of ANY and can occur almost anywhere.  #OTHER
makes
> this approach more honest.)
>

After thinking about it a bit, I thought that something like #OTHER was also
generally too loose, which is why my proposal on validation and namespaces
allowed you to specify which namespace to use.  After all, CML might import
several different namespaces, but at some particular point you want to specify
there should be an equation here.  If you can designate the namespace (i.e.,
<!ELEMENT html ( head, (body | frameset | layer | MATH:: ), tail ) >), you can
ensure that.

However this looks reasonable as a simplification for the first round.  The
more general question of namespace architecture will take a lot more
discussion, especially if it must also fit SGML.

Matthew Fuchs
matt@wdi.disney.com

-- 
Received on Friday, 27 June 1997 13:00:07 EDT

This archive was generated by hypermail pre-2.1.9 : Wednesday, 24 September 2003 10:04:44 EDT