xml-dev - Re: XLink a special case in the self-describing Web?

["Steven R. Newcomb" <srn@techno.com>]

> > (1) XML Namespaces do not provide a way for a single element to
> >     conform to an element type in each of several schemas.  Therefore,
> >     there is no way for a single element to be recognized as
> >     conforming to both the X:Foo and the Y:Bar element types.

> That is correct as stated, but it reflects a misconception.
> Namespaces provide nothing but a superficial mapping of GIs and
> attribute names into so-called "universal names", which are simply
> an ordered pair of the form {string, Name} where "string" has the
> syntax of a URI.  The SGML/XML semantic model is unchanged.

Well, OK, but this "misconception", as you put it, is implicit in
every single one of the industrial uses of XML Namespaces that I have
so far encountered.  Calling it a "misconception" seems to me merely a
way to deflect criticism from formalists like me, while at the same
time leading the public away from something that enables information
interchange in a powerful and potentially nonproprietary way, and
toward something that isn't as powerful and is far more likely to
engender system-vendor dependencies in everybody's information.  The
SGML/XML semantic model may be unchanged, but it is, in fact, being
replaced with something that doesn't work in the public interest,
under the banner, "Down with those #$% DTDs!"  We need to acknowledge
that fact.  It is not helpful to retreat into statements like "There
is nothing semantic about XML Namespaces", when in fact most people
use names in order to label things meaningfully.  Most people
literally can't imagine using names for any other purpose.

    In the Biblical creation myth, Adam's task, as assigned by Jahweh,
    was to name everything.  I doubt that the idea of there being a
    possibility of names with no semantics would ever have occurred to
    Adam, and maybe not even to Jahweh.  If I name a class of things
    "squirrel", the only reason I do that is that all members of that
    class share the characteristics of squirrels.

> Note that by definition X:Foo and Y:Bar cannot represent the same
> universal name, but X:Foo and Y:Foo can and do if the prefixes X:
> and Y: are bound to the same string.

I wasn't clear.  When I said "X" I meant "whatever X means".  I wasn't
making a statement about syntax.  Please read "X" as "the universal
name-prefix for which X is the abbreviation".

> > So, if my above understandings are correct, I tentatively conclude
> > from this that XLink is not a namespace or a schema in the usual
> > sense, because, among all of the kinds of element definitions that
> > are possible, only the XLink element types are, de facto, exempt
> > from the "one element, one element type name in one semantic space
> > of element type names" rule.

> The namespace for XLink at present is
> "http://www.w3.org/1999/xlink".  The current XLink draft gives
> meaning to the universal attribute names
> {"http://www.w3.org/1999/xlink", "type"},
> {"http://www.w3.org/1999/xlink", "href"}, and others, but does not
> give meaning to any universal GIs.  You are free to use a name such
> as {"http://www.w3.org/1999/xlink", "simple-link"} as a GI if you
> want, but XLink does not say what it means.

That's what I thought.  So the actual generic identifier of an XLink
element is immaterial to its recognition by any processing system as
an XLink element.  The question, "What kind of element is this?" is
not answered by the generic identifier (element type name); it is
answered by attributes other than the generic identifier.  (The
generic identifier is itself just an attribute; it is the value of the
one-and-only nameless attribute, which all elements are required to
have.)

> > Can anybody create sets of attributes, just as has been done with
> > XLink, that will constitute a semantic space, and thus effectively
> > have elements identify themselves as conforming to certain element
> > types without requiring that the generic identifier be used to
> > identify the element type?
> 
> Yes, indeed.  If one is sufficiently canny, one can do so in conformance
> to the rules of SGML architectures as well, as I believe XLink does.

Well, almost but not quite.  The basic difference has to do with
establishing a context for each of the pseudo-element-types that XLink
describes.  With architectural forms, there is always a known set of
contexts within which an element of a particular type is constrained
to appear, even if that set of contexts is "anywhere at all", as is
(correctly, I believe) the case with XLink elements.  I haven't found
any formal expression of that "anywhere at all" context constraint in
XLink such that the same kind of trick could be used for element types
that really should only appear in particular contexts.  

  (Actually, XLink locator elements should only appear inside extended
  XLinks, but I haven't found a formal machine-interpretable
  expression of that constraint that I could use to define and
  constrain architectures other than the XLink architecture, using the
  same software to validate instances for conformance with such
  context constraints.  We could do at least that much with DTDs.)

Validation of the syntax of namespaces, as they are actually used in
documents, when they are arbitrarily mixed with other namespaces, is a
basic business requirement that W3C designs have so far ignored.  The
W3C evidently expects all XML processing software to re-invent and
re-implement all aspects of syntactic validation of every Namespace,
including functionalities needed by the overwhelming majority of
business namespaces.  It's a recipe for Babel, and overcoming the
effects of that Babel is impossibly burdensome for developers of
industrial XML Schemas, when an industry must be served by more than
one software vendor, and when its information interchange
architectures must incorporate any number of extensions to the
industrial vocabulary, and the industrial vocabulary must be able to
be mixed with the vocabularies of any number of other namespaces.

> > If anybody can already do this, is this a
> > methodology to which XML Schemas can provide validation services, by
> > checking to see whether all of the attributes have been used in
> > syntactically valid ways?  If so, how?

> I think so, but I don't know exactly how.

Neither do I, and that's the heart of my question.  It would be
wonderful if XLink, for example, were defined in such a way that we
could use the same formalizing definitions for inheritable
architectures other than the XLink architecture, in addition to XLink
itself.

The ISO architectural forms syntax is just one way to accomplish that
goal.  Instead of repeating my usual rant extolling the virtues of ISO
architectural forms, let me instead (try to) be both syntax-agnostic
and standardizing-body agnostic.  What are the alternative formalisms
that meet the commonplace business requirement that a single element
be recognized as conforming to both the X:Foo and the Y:Bar element
types?  XLink demonstrates a way -- for exactly one architecture,
namely itself.  Is W3C developing a *general* solution that can be
used for *all* architectures?  Is anyone else in the running?

Or is this a problem that W3C's vendor-members simply don't want to be
solved?  If so, it's already too late, because there is already an
international standard that solves it, and that internationally
standard solution -- architectural forms -- is already being adopted
by the financial community, primarily because there is no relevant W3C
Recommendation.

-Steve

--
Steven R. Newcomb, President, TechnoTeacher, Inc.
srn@techno.com  http://www.techno.com  ftp.techno.com

NEW ADDRESS effective May 1, 2000:

voice: +1 972 359 8160
fax    +1 972 359 0270

405 Flagler Court
Allen Texas 75013-2821 USA

***************************************************************************
This is xml-dev, the mailing list for XML developers.
To unsubscribe, mailto:majordomo@xml.org&BODY=unsubscribe%20xml-dev
List archives are available at http://xml.org/archives/xml-dev/
***************************************************************************