Re: Thoughts on namespaces

On Fri, 23 May 1997 10:18:19 -0400 (EDT) Steve DeRose said:
>I'm struck by how close to CONCUR this all falls: What we're talking
>about is a single document that has (at least parts of) several DTDs in
>use. It is clearly more work to support that if you must truly combine
>the DTDs (move some/all dcls from one into the other, perhaps with
>renaming), than if you can just use them both (which CONCUR does).
> ...
>I think I'd favor CONCUR for this particular kind of use, since it is
>already defined, SGML compatible, and a pretty good fit. It also allow
>you to add the "borrowed" tags without so much as touching the local
>ones (whose DTD, presumably, would be considered the base/default).
>Also, the complex bits of CONCUR are less troublesome in the limited
>usage we'd be making of it. The issues we'd have to resolve with CONCUR
>include:
>
>a) It only handles one level of naming beyond the GI, not multiple
>levels; this may be sufficient for the particular case we're talking
>about.

True, both about the limit and about the likely sufficiency of one
level.

>b) Each DTD must cover the entire document, which we definitely don't
>want.

Jean-Pierre Gaspart has already dealt with this, I think -- he showed
me a very nice system a few years ago, which constructed complex
DTDs from DTD fragments (one for tables, one for special lists, one
for basic text chapter/section organization, etc.  Each of these
was in a concurrent document type, so he was guaranteed protection
against namespace collisions.  (I don't know what he did about
ID/IDREF links, but there has to be a solution.)

His basic approach was simple:
  1 define the DTD you really want, for specialized information
    packets like tables, digital signatures, what-have-you.
  2 Now give this namespace / domain a name.  For tables,
    I'll use T, for digital signatures D, etc.
  3 Wrap the outermost element(s) of your existing namespace DTDs
    in an element for the domain.

For example:  let's say my table DTD has two kinds of tables:
simple tables (TABULAR) and full tables (TABLE), sort of like (La)TeX.
My reference to the DTD for tables looks like:

  <!DOCTYPE T PUBLIC "foo" "http://tables.r.us.com/dtd/tables.dtd" [
    <!ELEMENT t (#PCDATA | table | tabular)* >
  ]>

(The DTD stored externally may supply the definition for T if it
likes; but if I refer to the DTD as shown, then I can specify the
domain name myself.)

It's a key component of Jean-Pierre's approach, of course, that the
parser parses all active document types at the same time, so the
application sees tables and chapters and footnotes in proper sequence.

>c) There is no mechanism to constrain relationships between the DTDs
>(like, that their elements can't cross in non-hierarchical ways, a
>constraint I should think we want very much for this particular
>application). Of course, we could state this as a majorly simplifying
>constraint on XML's use of CONCUR.

Hmmmm.  Well, we could, yes -- at least, I think so.

With some rules like this, I think CONCUR might in fact be our best
bet.

>B and C are not intrinsic to the notion of CONCUR, and I think they
>could be removed with minimal syntactic disturbance; but they are there
>and could not be removed merely by XML convention. The multi-level may

I think C *could* be removed by XML rules, just as XML removes the
precisely equivalent freedom to allow the entity tree structure
to be asynchronous with respect to the element tree structure.

Which is not to say that good wording will be easy to come by.

Thank you, Steve!  A new reason to argue for CONCUR!

There is one down side, of course:  so few SGML parsers actually
support CONCUR now.  Sigh.


-C. M. Sperberg-McQueen

Received on Friday, 23 May 1997 18:38:24 UTC