Re: [xtm-wg] Comments on the syntax proposal

[Murray Altheim <murray.altheim@eng.sun.com>]

Sam Hunting wrote:
> 
> [lars]
> The specification should make it clear that conforming XTM 1.0
> implementations must use namespaces ...

We are compatible with XML 1.0 plus XML Namespaces, but we do not
need to allow everything (such as namespace scoping and defaulting)
to be compatible. We allow a subset of that functionality, which 
could easily be argued is in its gamut quite broken. Only XML Schemas
attempts to solve the problems created by the XML Namespaces Rec,
and I would hate to require an XML Schema for such a simple document
type.

> Can't we get the semantics of xlink processing without necessarily
> having an (namespace-using) link processor?
> 
> [lars]
> ... and that recognition of names defined by XLink, XBase and XTM must
> be based on a namespace view of the document rather than an XML 1.0
> view. ...
> 
> Ditto on density, and what is a "namespace" view? What does it buy us
> that XML 1.0 processing does not?

We are completely compatible with XLink, XML Base, XML 1.0 and XML 
Namespaces. We use a subset of each. XTM documents conform to all of
the above-mentioned specifications. We can honestly claim to be completely
conformant. In the current 0.9 draft specification I have listed ISO 13250,
XML 1.0, XLink, XML Base, XML Names and the IETF RFC for URIs, since all
are used in XTM either conceptually or literally, and we are conformant
with all.
 
> [lars]
> In other words, the namespace prefixes used in the XTM 1.0 DTD are not
> the only possible namespace prefixes for these namespaces.
> 
> You mean "xlink:" could change to something else? How do we do DTD
> validation, then?

We as our own "standards body" can define our constraints any way we
like. By restricting the prefix for XLink to "xlink" in the DTD we 
disallow other prefixes, but you'll note that other W3C DTDs such as
SVG do this as well. There is precedent, even in the W3C itself. 

Our other option is to parameterize the prefix as I've done in XHTML
modularization. It's a complex solution, makes the DTD much more difficult
to read, and allows XTM markup to contain unnecessary variation. We have
already decided (in Dallas, by acclamation) that within a <topicMap>
element (which cannot be prefixed, eg. <xtm:topicMap>), no non-XTM
markup is allowed. We don't "do" namespaces the way well-formed XML
plus Namespaces allows. We aren't interested in allowing this. Why
would we? To allow companies to create proprietary markup inside of
an XTM topic map that would privilege their topic maps and break the
principle of validation and interoperability? We are about "interchange",
not playing the game of mixing via XML Namespaces. This is my 
understanding of the decisions made by the Authoring Group.

Murray

...........................................................................
Murray Altheim, SGML/XML Grease Monkey     <mailto:altheim&#64;eng.sun.com>
XML Technology Center
Sun Microsystems, 1601 Willow Rd., MS UMPK17-102, Menlo Park, CA 94025

      In the evening
      The rice leaves in the garden
      Rustle in the autumn wind
      That blows through my reed hut.  -- Minamoto no Tsunenobu

-------------------------- eGroups Sponsor -------------------------~-~>
eLerts
It's Easy. It's Fun. Best of All, it's Free!
http://click.egroups.com/1/9699/1/_/337252/_/974837875/
---------------------------------------------------------------------_->

To Post a message, send it to:   xtm-wg@eGroups.com

To Unsubscribe, send a blank message to: xtm-wg-unsubscribe@eGroups.com