Re: [xtm-wg] Version number in URI.

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

Jason Diamond wrote:
> 
> Hi.
> 
> > The idea that XTM would be "cluttered" by having multiple namespaces
> > misunderstands the concept of namespaces (which seems to be fairly
> > common).
> >
> > If we add <associationTemplate> or some other new element type to a
> > post-1.0 XTM, it shouldn't occur within the same namespace as 1.0, as
> > it simply *wasn't* in that namespace. A namespace is *not* an open-ended
> > gamut of possible names, it is the closed set of names within a space.
> > That some people within the W3C seem to get this confused doesn't help
> > matters.
> 
> While I agree that your position is sound, the Namespaces Recommendation
> does not specify any such constraint.

The XML Namespaces Recommendation leaves out a whole lot of information
about namespaces that the W3C has spent *millions* of dollars of member
time sorting out over the past few years. I wouldn't hold up that document
to too much light.

[...]
> I agree that a lack of any sort of versioning scheme would be a serious
> mistake. I disagree that namespaces are the best way to achieve this,
> though, as evidenced by XSLT.

XSLT is hardly a typical example, being a *very* special case. It's not
even a markup language in the same sense as XTM, in that it cannot be 
validated according to a DTD. It is complex and designed under very different
requirements. Our scope is decidedly much simpler -- we deliberately don't 
want to see mixing of the XTM namespace with others. 

[...] 
> Since XTM is supposed to be for interchange between machines and not humans,
> maybe this is a moot point. But you already have taken steps to ensure that
> it's as convenient for humans to author as evidenced by the requirement that
> XTM use the default namespace (DTD issues notwithstanding) and the fact that
> role was changed to roleSpec in order to avoid confusion with xlink:role
> (even though there is absolutely no ambiguity from a machine's point of
> view).

We don't need to pay much attention to XML Namespaces, except to be compatible
with them. This is by design, not accident. We aren't using xlink:role as we
found we were unable to use most of XLink due to design restrictions such as
those on nesting depth. I'd originally thought we'd be able to take much more
advantage of extended and other link types.

> From an implementor's perspective, I think that it makes more sense to check
> a version attribute on the document element rather than parsing the entire
> document and hoping that I don't encounter any elements in another
> namespace. [...]

Huh? Checking an 'xmlns' attribute is identical in function to a 'version'
attribute, in that both appear on the document element. There's no
ambiguity in our current design, such as you suggest. As we state in the
XTM 1.0 spec, <topicMap> elements must validate according to the XTM DTD,
which includes matching the #FIXED 'xmlns' attribute. Absent validation,
the 'version' attribute buys you no more guarantee than an 'xmlns' attribute.

> You could require that the namespace declaration for the new
> version appear on the document element and use that to indicate whether or
> not a given implementation is capable of processing it. Imagine what those
> declarations will amount to four or five versions from now. That's the
> namespace clutter that I was referring to.

Yes, we could have implemented versioning via a separate 'version' 
attribute, but then we'd have two separate places to serve essentially
the same purpose. If we want to state the XTM 1.0 namespace is a closed
set defined by the elements and attributes found in the XTM 1.0 DTD 
(which we do, for all sorts of good reasons), then having a separate
versioning mechanism is redundant. I don't see TopicMaps.Org putting
out three or four or five versions of XTM as you surmise. That would
be extremely counterproductive. One of the typical errors in a team
of clever people is knowing when to stop. If the XTM 1.0 design is
correct, it is in the best interests of everyone that it be as stable
as possible. This is very unlike HTML, which has since the beginning
been a victim of featuritis. It's also since the beginning been an
interoperability and standards mess.

As for clutter, if five versions of XTM do ever exist, this is still
from an implementor's POV an extremely simple issue. 

You'll find a million opinions on this issue inside and outside the W3C,
but what it comes down to is this: there's nothing inherently wrong with
providing versioning in the namespace URI. This design decision came 
about after a great deal of careful consideration, and I believe it
represents the best way to guarantee the long term interoperability of 
topic maps and applications that process them.

Finally, the TopicMaps.Org Authoring Group just went through a laborous
and costly process in designing and approving an XTM 1.0 Specification.
The idea that we are still in "design mode" on XTM 1.0 is to me a very
troubling thought, one that would tend to make me abandon this effort
and look toward groups that can deliver finalized specs. The hardest 
thing in the world to do sometimes is to just leave something alone.

Murray

...........................................................................
Murray Altheim                            <mailto:altheim&#x40;eng.sun.com>
XML Technology Center
Sun Microsystems, Inc., MS MPK17-102, 1601 Willow Rd., 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

------------------------ Yahoo! Groups Sponsor ---------------------~-~>
eGroups is now Yahoo! Groups
Click here for more details
http://us.click.yahoo.com/kWP7PD/pYNCAA/4ihDAA/2n6YlB/TM
---------------------------------------------------------------------_->

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

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

Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/