Re: Update on namespaces

It has suddenly dawned on me that this "namespaces" debate is
really about inheritance of architectures.  Sorry, I thought
everyone was discussing namespaces.  No wonder I had no idea
what was going on.

It will surprise no one that my opinion is that Architectural Forms
are the right way to inherit architectures.  Everything needed is
already in XML, except <!ATTLIST #NOTATION ...>, which strikes me as a
trivial thing to add that should be there anyway, so that notation
processors can be passed explicit arguments specified in the instance.
The supporting software for them is already there, too.  

Tim's arguments against AFs are very weak.

[Tim Bray:]
> 2. Use Architectural Forms (maybe just calling them reserved attributes)

Why not use the ISO name for them: "Architectural Forms"?  Is it
always necessary to conceal the fact that the some of XML's ideas
also appear in the HyTime standard?  If so, may I ask why?

> This was argued by quite a few people, most eloquently by James Clark.

This is no surprise, either.

> This has the appealing characteristic that no changes whatsoever are
> required, and you can do everything with an XML parser.

Well put.

> It has the
> downside that if you want to avoid huge masses of attributes on everything,
> you have to start parsing DTD syntax to get the defaults.

This argument makes little sense.  What "huge masses of attributes"?

If an element inherits the characteristics of the HTML GI "a", then it
must be able to have a "url" attribute.  In fact, no matter what the
inherited semantic is, there may be attributes that are needed to
allow the semantic to be expressed.  So you get these "huge masses of
attributes" no matter what.  The only extra attribute in an
architectural form is the one used to declare the fact that, for
example, it inherits the semantics and syntax of "a" elements in the
HTML architecture.

The whole notion of inheritance is an object-oriented one.  It is
meaningless to inherit something without knowing what the model of the
inherited thing is.  Ergo, modeling is required for inheritance;
there must be a model somewhere.  If the model (the DTD or meta-DTD)
is not parsed, that's ok, but it still has to exist somewhere, even
if it's only built into the software that processes the data expressed
according to the model.  And, each thing that claims to conform to the
model must actually make that claim: it must refer to the model.  

How to refer to the model?  One way is to make the GI itself parsable
into two (e.g. colon-separated) fields.  You use the first field to
give the name of the element type in the inherited architecture, and
the second field to give the name of the element type in the
document's architecture.  This makes a lot of sense, until you come
upon a situation in which you want to inherit from two
well-established architectures that use the same GI.  What to do about
the name conflict?  (Can anyone reading this deny that two important
architectures may use the same GI in different ways?)  But that's just
the beginning.  What if you want to do multiple inheritance, in which
the same element type is one thing in one inherited architecture, and
another thing in another?  This is a commonplace requirement in
object-oriented design, because it makes possible the re-use of
software.  It will be commonplace in SGML documents, because control
over architectures MUST be distributed in organizations and in the
world, or we wind up with monolithic architectures that succumb to
"feature-itis".  DocBook, for example, is getting pretty big, but it
can still be saved from becoming cancerous by dividing it up into
architectures that inherit from each other.  ODA (Office Document
Architecture) killed itself by growing out of control.  There are many
other examples; the first one I ever saw myself was the PLATO system.
If XML does not offer the ability to support distributed control of
architectural models, it will not live up to its promise.  (It's no
problem for me either way, but I sure hate to see all this effort by
so many smart, dedicated, and public-spirited people wasted.)
Multiple inheritance is not a luxury, it is ESSENTIAL in an
increasingly complex world in which many simpler things must be
combinable into more complex things, losslessly and reliably.

So the GI-divided-into-fields idea places unacceptable limits on
functionality.

> We are 
> encountering HUGE, MASSIVE resistance to this in web-land.  When we explain 
> that it's not that hard, we are told to go away, you've given us elements 
> and attributes, we like elements and attributes, why can't we do everything 
> with elements and attributes?

I don't understand the merit of this argument.  Are we supposed to
make design judgments based on the ill-considered clamorings of the
ignorant?

> I've also heard claims that the AF technique 
> falls apart in certain examples, but I haven't seen those examples yet.

I don't understand this argument, either; it's hearsay.  Bring forth
the evidence, so it can be judged on its merits.  I have reason to
believe there is no valid evidence to support this claim.

> This a semi-upside that if we need multiple inheritance (I think we
> don't, and would prefer to avoid it if we can) it's easy to express if
> not to understand.

Why should multiple inheritance be avoided?  On the contrary, it
should be embraced as the biggest productivity enhancement ever
conceived.  What's so hard to understand about it?  Isn't it
intuitively obvious what this means:

<mylink html=a General.Motors=partref>

> 3. Use an all-instance syntax
> 
> This is something along the lines of the the colon-prefixing that
> was proposed by both Microsoft and the Japanese WG8 submission, e.g.
> <book:price>11.99</book:price>.  This has two downsides: it requires
> a change in XML-lang (albeit not much, just allow ':' in namechar), and
> you can't get all the information you need from a normal SGML parser
  ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
> without some postprocessing.
  ^^^^^^^^^^^^^^^^^^^^^^^^^^^^

Yup.

> It has a big upside in that all the
> information you need is right there in the document and lightweight
> processors get at it easily.  It's more in the XML style in that
> all the info is right there in the instance and you don't need
> any help to figure out what's going on.

This implies that with architectural forms the instance can't have
this same information unless the DTD is parsed, but that is not true!
Look, in the below example, it's all there in the instance!

<mylink html=a General.Motors=partref>


Best regards,
--Steve

             Steven R. Newcomb   President
         voice +1 716 271 0796   TechnoTeacher, Inc.
           fax +1 716 271 0129   (courier: 23-2 Clover Park,
      Internet: srn@techno.com    Rochester NY 14618)
           FTP: ftp.techno.com   P.O. Box 23795
    WWW: http://www.techno.com   Rochester, NY 14692-3795 USA

Received on Friday, 20 June 1997 13:08:59 UTC