W3C home > Mailing lists > Public > www-rdf-interest@w3.org > January 2002

Re: rdf-ns-prefix-confusion

From: Uche Ogbuji <uche.ogbuji@fourthought.com>
Date: Tue, 15 Jan 2002 07:47:41 -0700
Message-Id: <200201151447.g0FElfU03235@localhost.localdomain>
To: "dehora" <dehora@eircom.net>
cc: "www-rdf-interest" <www-rdf-interest@w3.org>
> > From: Uche Ogbuji 
> > Why the insistence that using the namespace of an attribute 
> > directly be an 
> > inviolate principle in RDF?  Why not defer to the namespace 
> > of the owner 
> > element in some cases as a convenience?
> It's simple to generate.

I don't understand this.

> It's simple to accept.

Easy for you to say, you seem to have already accepted it.  I haven't.

> It requires no shared natural practice outside the RDF specs.

There is something wrong with consistency with other systems?  OK, why don't 
we also use processing instructions for constructs such as parseType=Resource?

> It's explicit (be clear!).

No less explicit that what I'm proposing.

Again, are you saying that

<xsl:variable name="spam" select="eggs"/>

is not explicit or clear?

> It's unambiguous.

My suggestion is not ambiguous either.

> It's easier to read.

To you, maybe.  The cornerstone of my contention is that my suggestion is 
easier to read.

> It's simple to upgrade existing data.

I think this lies outside the question.

> It's robust with respect to the namespaces spec.

I doubt you can defend this claim without a very strange definition of 

But again, one test is whether you think that XSLT is not robust WRT the 
namespace spec.

> So why prefer to defer
> to the namespace of the enclosing element?

I've detailed my reasons in this thread.

Uche Ogbuji                               Principal Consultant
uche.ogbuji@fourthought.com               +1 303 583 9900 x 101
Fourthought, Inc.                         http://Fourthought.com 
4735 East Walnut St, Boulder, CO 80301-2537, USA
XML strategy, XML tools (http://4Suite.org), knowledge management
Received on Tuesday, 15 January 2002 09:48:01 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 22:44:34 UTC