OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

topicmaps-comment message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]


Subject: RE: [xtm-wg] Version number in URI.


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.

"[Definition:] An XML namespace is a collection of names, identified by a
URI reference [RFC2396], which are used in XML documents as element types
and attribute names."

Nowhere in the document does it mention that the collection must be closed.

> > >The same can be said for PSIs. Do we really want to have to
> remember in what
> > >version of XTM a PSI was introduced?
> >
> > What Jason says makes a lot of sense. I would like the AG to
> > consider this issue and take a decision in Austin.
>
> The version number is essential if we expect there to be future
> alterations
> to XTM that include new features. This will allow processors to know that
> "xtm/1.0" namespace-compatible processors and topic maps are *different*
> from newer versions, e.g., they include templates or other new syntax.
> Absent versioning we mix all of the version's namespaces and are unable
> to differentiate, which I believe would be a serious interoperability
> mistake.

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.

The recent working draft for XSLT 1.1 introduced a new element,
<xsl:document>, into the original XSLT namespace
(http://www.w3.org/1999/XSL/Transform). The working draft includes this
note:

"NOTE: The 1999 in the URI indicates the year in which the URI was allocated
by the W3C. It does not indicate the version of XSLT being used, which is
specified by attributes ..."

Every valid stylesheet is required to specify the XSLT version that it
conforms to with a version attribute on the document element. Stylesheets
with a version of "1.0" that include an <xsl:document> element or any other
element in the XSLT namespace generate an error while stylesheets with a
version of "1.1" do not.

They could have mandated that the <xsl:document> actually use a newer
namespace (<xslt11:document>?) but this would turn out to be more of a
nuisance than it's worth for the countless developers (including myself) who
still write XSLT code, by hand, every day.

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).

>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. 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.

Thanks,
Jason.


------------------------ 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/ 




[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]


Powered by eList eXpress LLC