Re: Thoughts on namespaces

[Paul Grosso]
> But why would the mymess DTD want to have an element declaration
> for, say, HTML's p element and how does such a declaration interact
> with the HTML's declaration?

I was working for SGML'86 compatibility.  There isn't a way to
incorporate elements from another DTD *under a new name* in SGML'86.
I was also assuming that most of the people looking for inherited
semantics will probably not be writing their own DTDs; this was an
example of the virtual DTD for such a document.

> I would think that html:p (I prefer one colon) would have--at least
> by initial default--the content model from the HTML DTD.  In fact, I
> expect a given instance of an html:p very likely came from an
> existing HTML document and may well have other elements from the
> HTML DTD embedded in it.  If you have a declaration for html:p at
> all in mymess, I would expect it would be to allow html:p to contain
> elements--from the tei, faq, and mymess DTDs--in addition to those
> the HTML DTD already allows.

In the theoretical DTD, yes.  I was going on the assumption, which I
should have made explicit, that most namespace users are simply going
to grab semantics from various places and mix-and-match.

<?XML version="1.0" encoding="iso8859-1"?>
<?XML-schema source="-//W3C//DTD HTML 3.2 Final//EN" name="html"?>
<?XML-schema source="+//ISBN 1-886034-00-1//DTD TEI P3//EN"
name="teip3"?>
<mymess>
<html:h1>This is a mess.</html:h1>

<html:p>What's going on <teip3:xref target="ID
(here)">here</teip3:xref>?</html:p>

<html:p id="here">I don't know.</html:p>
</mymess>

> I think I understand the multiple-namespaces-in-an-instance idea
> (though with lots of outstanding questions remaining), but I don't
> understand your "combined DTD" idea.  Can you elaborate on what
> requirements it addresses and how it's supposed to work given some
> of my questions above?

I'm trying to make it possible to use namespaces without YASA[*].
This proposal requires addition of another namechar to XML's hardcoded
SGML declaration, and application conventions for using that new
namechar, but doesn't require ISO 8879 to change.

If people think that good namespacing is going to require such a
change no matter what, then my proposal is irrelevant; if 8879 needs
another change for this, then there are better ways to do it.

[Eliot Kimber]
> Why not use architectures for this?  Instead of qualifying the GI,
> you create a local element type name and then name the form from
> which it is derived (here deriving "mylink" from the HTML element
> form "A"):
> 
> <mylink html="a" href="foo"/>

[...]

> While I can see the appeal of being able to do some sort of "import"
> of one DTD into another, I think the basic requirements can be
> solved adequately (if not ideally) using existing mechanisms without
> the need to modify XML or SGML syntax.

I think that what the requestors are requesting is the ability to say,
"Gimme stuff from HTML and gimme stuff from MathML and know what to do
with them, without me having to make a DTD that explicitly merges them
all."  Using arch forms, while elegant, requires either a DTD for
#FIXED attributes or explicit attributes on every element instance.
(Or a #CURRENTy thing, but let's not go there again.)

I'm not emotionally invested in this proposal in any way; I tend to
write my own DTDs from scratch for everything I do.  I think what we
need before further discussion is a clear statement of what goals
namespace proposals should be addressing; the "minimum necessary to
declare victory" again.  All the proposals I've seen, including mine,
solve slightly different problems.

-Chris

[*]Yet another SGML amendment.
-- 
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 15:06:04 UTC