Re: Namespaces, the universe, and everything

Eliot has also been addressing these issues over in his work with
the Medical people, and sent me the following, which at his request,
I'm passing on to the WG. -T.

Eliot from here down:

I've been silent on this issue (except for one post presenting my AF usage
proposal) largely because I've been too busy with getting the HyTime
standard out and client work to think about this very difficult issue.

Here is my feeling at the moment [Tim, feel free to share the following as
you see fit, including on the WG]:

1. Architectural forms do in fact solve most (if not all) of the name space
problems. They do it in what I think is a pretty elegant way considering
that they depend on existing SGML methods and limitations.  They offer a
number of advantages, not least of which is that the whole architectural
tower rising over a document can be completely ignored by unaware
processors.  Combined with subdocuments, most (but not all) of the
requirements I've seen coming out of the name space discussion can be
satisfied.  I know this in my heart and mind.  Convincing others that this
contention is true is difficult and time consuming, and I don't fault
anyone for being initially daunted by the abstact and formal nature of the
mechanism.  I've made it my life's work to educate the world about these
technologies, which are, at their core, fairly simple and natural to use.

2. There seems to be a legitimate requirement for direct schema munging of
the sort reflected in most of the non-AF proposals I've seen.  This has
some qualities that AFs can't provide.  It also has some drawbacks and
limitations that AFs avoid.

3. I agree with David Durrand that the initial negative reaction to AFs is
short sighted.  However, I don't think it's because the people having the
reaction don't know what they're doing.  I think it's because they haven't
had 15 years to wrestle with the problem.  They are, by and large,
short-term thinkers, for good or ill, with short-term requirements that
need to be met.  Proposals with a lot of conceptual overhead require time
for reflection, time they don't have.  Applying what they know from other
domains is a sensible and natural reaction.  While we might disagree with
their technical solutions, there's no profit in simply naysaying them out
of hand.  

4. AFs and more direct name munging can be used together (the munged names
are, after all, ultimately just element types, which can always be derived
from architectures).

I have a number of serious concerns with the various schema munging
proposals, to the degree I've had time to think about them at all, in
particular:

1. The requirement that all name spacing be exposed in the instance.  I
think this is ultimately self-defeating, because it builds in dependencies
on document authors/generators that you don't have with AFs (at least with
explicit DTDs).  Semantic derivation can't be retrofitted onto documents
without modifying the instances.

2. Multiple levels of derivation all take up space in the instance.  With
AFs, multiple levels of derivation are visible only to architectural
processors.

3. Multiple inheritance is difficult or impossible.  With architectures,
multiple inheritance, both of the same element from forms in different
architectures and of the same element from different forms in the same
architecture, is possible (although this second case is non-obvious and a
bit tricky, although inherent in the general architecture mechanism).

4. Addressing of elements may be significantly complicated, because there
may be multiple ID or entity name spaces within a single instance.  Not
impossible to manage, just a complicating factor.  Note, however, that
HyTime's general name-based addressing facility is perfectly capable of
dealing with such name spaces because the mechanism for defining name
spaces is completely generalized.  However, simple ID/IDREF may no longer
be sufficient.

5. It seriously confuses the syntax/semantic issues that SGML (and HyTime)
are careful to keep separate, primarily through the use of subdocuments to
construct compound documents.

However, from my experience in evaluating the Japanese proposal to WG8, it
appears that all of the above concerns can be addressed by reasonable
technical approaches.  Therefore, it seems likely that a useful namespace
approach that is consistent with existing SGML designs and design
principles can be developed and probably should be.  I'm certainly not
competent to accept or reject any proposal at the moment.  I don't think
there's been nearly enough thought or experimentation yet and seriously
doubt the ability to define a mechanism by YE97 that will stand the test of
time.  However, I wouldn't impede the development of approaches that didn't
require egregious violation of SGML syntax rules--obviously the
experimentation has to happen and I don't see why we shouldn't let the
people with the requirements do it.  I'm not so arrogant as to think that
the SGML world can provide all the answers to these issues and I'm
certainly willing to listen to and learn from people outside our little
world.  I know that advances in any well-entrenched discipline must come
from outside.

As for the issue of medical records, I just don't know the answer.  My
personal feeling is that we should explore the architectural approach until
we break it.  In the mean time, other name space approaches will have had
time to mature.  We should carefully capture our name space requirements so
that we can inject them into the discussion in the most productive form
possible (i.e., devoid of implementation suggestions).

My confidence in the architectural mechanism makes me think that, as the
name space issue is explored in more depth, people with both come to
appreciate the benefits of architectures and better see the limitations of
name munging approaches.  I say, lead by example.  If you build it, they
will come....

Cheers,

E.

Received on Thursday, 19 June 1997 15:36:28 UTC