W3C home > Mailing lists > Public > www-rdf-interest@w3.org > May 2001

Example problem with QNames and RDF was: Re: QName Problem Isn't One

From: Jonathan Borden <jborden@mediaone.net>
Date: Mon, 7 May 2001 13:07:41 -0400
Message-ID: <0c8901c0d718$3ab45e60$0a2e249b@nemc.org>
To: "Brian McBride" <bwm@hplb.hpl.hp.com>
Cc: "RDF Interest" <www-rdf-interest@w3.org>

First a very simple example:

The task assigned is to create an XSLT transform which adds 1 to the number
represented by the value of an element qualified by the XML Schema namespace
with a local name "decimal" (i.e. "xsd:decimal"), a fragment of this

<xsl:stylesheet xmlns:xsl="..."


<xsl:template match="xsd:decimal">
        <xsl:value-of select="1 + number(text())"/>

At this point several people are probably wildly waving their arms
suggesting that we use a different namespace URI in RDF applications.

My response is: if you care about interoperability with XML and XML Schema,
then you need the QNames to match because QNames are how datatypes are
refered to in XML, and QNames are how elements and attributes are matched in
XPath and on and on.

If you don't care about XML compatibility, then why use XML Schema
datatypes? What to people hope to accomplish by this in the absence of using
XML and XML related software?

Of course we can do the following:

<xsl:template match="fubar:decimal">

but just as easily I can do:

<xsl:template match="rdf_datatype:decimal">

if we aren't going to use the _same datatypes_ then why confuse the heck out
of people.

An analogy would be to the difference between the numbers:




sure they are close, but is anyone really suggesting that these two values
are the same? If you consider two namespaces close enough as they only
differ by a single character, that's akin to asserting a [daml:equivalentTo,
xsd:decimal, xsd:int] which might be fine for the IRS but might cause
problems for NASA.

(for non-US citizens, that is a play on the phrase: "close enough for
government work")

Received on Monday, 7 May 2001 13:24:09 UTC

This archive was generated by hypermail 2.3.1 : Wednesday, 7 January 2015 15:07:36 UTC