RE: SD5 - Namespaces - New Version 2

Paul Grosso wrote:
> I interpret this to mean you believe some attributes have "meaning"
> independently of the element they qualify, as "currency" has meaning
> independently of "price".  But, in general, do most attributes in fact
> have unambiguous meaning independent of the element?  (I doubt it.)
> 
> Why would you define a <price> element *without* a "currency" attribute?

You might always work in a single currency -- e.g. we have customers
such as Standard & Poors who have a PRICE element that reflects the price
of a share on the NY stock exchange...

I often see DTDs written with something like

<!Entity % golbalAttributes '
	id ID #IMPLIED
	LANG CDATA #IMPLIED --* would use #INHERITED if it existed *--
	DIR (ltr|rtl) "ltr" --* writing direction *--
    '
>

This is then applied to every element in case it's ever needed.

I can see that using namespaces, if they are defined in a way that
lends itself to this, could have uses for attributes.

Of course, this can also be done with something like (inventing syntax)

<!AttList Element001 #AUGMENT
    id ID #IMPLIED
    LANG CDATA #INHERITED
    DIR (ltr|rtl) "ltr"
>

for each element that one is going to use.  This is rather like having
to specify every Unicode/ISO 10646 code point explicitly in the SGML
declaration, in a way (although far less tedious).

I can also see that if you have two elements called title, one from
the society of indexers's taglist [note 1] for annotating a text for
making an index [2], and another from the Bodlian Library Taglist
for bibliographic reference, you will want to do the equivalent of
<(index|bibref)TITLE ...>
and specify the union of the attributes.  This is, if you will,
multiple inheritance [3].  It has been done well [3] and badly [3],
but when you need it, there's generally no other choice.

SGML is many things to many people: for some, it is a way of annotating
textual documents with markup, which is generally inserted in-band into
the text stream.  For others, it is a way of representing structured
objects [6], and the lessons we've learned in making programming languages
over the last 50 years may apply.  For others, it's something else yet
again, of course.  None of these views is wrong, but none of them is
complete.  As the SGML community grows -- I nearly said like a brain
tumor in a giraffe but I don't know exactly why -- we meet more and
more diverse applications, and we build conventions for using SGML
within these narrow but unconfined spaces.

Architectural forms are one such convention.  It could be that
::explicitly::labeled::generic::identifiers will become another
such idiom.  There are DTDs that use attributes with a fixed name --
sometimes to work around the SGML restriction of allowing only one ID
per element.
<fence sizeid="f27" eqnref="Equation_12" id="E202">...</fence>.


Flexibility comes at a price.  The price can be in increased complexity
of the software -- which we must avoid for XML, of course -- or it can
be in reduced robustness of documents -- and that is the path we
have chosen by making the DTD optional -- or it can be in increased
authoring cost -- SGML vs. MS/WORD, say.

If we add subclassing, multiple inheritance, named name spaces, references,
data typing and a full stack-based scope with closures of some sort for
use with #INHERITED, we will have something that is quite different
from the SGML of today.  Heck, _I'll_ buy it, no I'll take three,
but I am a part-time giraffe tamer and programmer.  I _want_ it.

But I don't want it at the cost of losing SGML support, and I don't
want it at the cost of making the parsers so complex that there are
less than a dozen of them.  If we wanted that sitution, we would not
have to do anything, because that's SGML today.

The minimal approach of allowing : in a name is interesting, but I
really wish we could leave it out for now and come back to it when
XML is published.  It needs to be thought out carefully.  We need
sample implementations.  We need to understand what we are doing,
before our gazelle becomes a hippocampus.

So let's try to walk before we try to run, as I don't want to hurt my
bare feet on all these pointy brackets and tiny colons.

Name spaces would be the biggest change to SGML since... er... since 1986, 
and one I've long wanted.  If we can wait for DSDs and Inherited
attributes and attribute patterns and being able to distinguish
#PCDATA from #PCDATA+, we can wait for name spaces.

We can't wait for XML deployment.

Lee

-- 
Liam Quin, lee@sq.com         | lq-text freely available Unix text retrieval
Senior Technical Consultant   | FAQs: Metafont fonts, OPEN LOOK UI, OpenWindows
SoftQuad Inc. +1 416 544-9000 | xfonttool (Unix xfontsel in XView)
http://www.softquad.com/      | the barefoot programmer



Notes
[1] I say taglist rather than DTD because I expect people will circulate
    lists of tags and attributes in the XML world rather than (or in
    addition to) DTDs with elements and attribute definitions.

[2] Although there is at least one real society of indexers, this is
    a fictional [5] example.

[3] Carghill, Tom, Multiple Inheritance Considered Harmful, Proc. IHLL,
    IFWE [4].

[4] I forget When Exactly.

[5] Tolkein, JRR, Essay on fiction and secondary belief, reprinted in
    Tree & Leaf, Hywin Press.

[6] ``I Object'', a letter to the _Times_, signed Disgusted, Tumbridge Wells

[7] This footnote is not referenced, so it isn't a resouce, but if
    you discuss it in future mail, it may become a link end.

Received on Saturday, 24 May 1997 15:11:50 UTC