W3C home > Mailing lists > Public > public-rdfa-wg@w3.org > October 2010

Re: Review of XHTML+RDFa 1.1 (http://www.w3.org/TR/2010/WD-xhtml-rdfa-20100803/) (Tom)

From: Toby Inkster <tai@g5n.co.uk>
Date: Fri, 29 Oct 2010 22:47:48 +0100
To: Thomas Steiner <tomac@google.com>
Cc: public-rdfa-wg@w3.org
Message-ID: <20101029224748.3d4068b4@miranda.g5n.co.uk>
On Fri, 29 Oct 2010 13:01:04 +0200
Thomas Steiner <tomac@google.com> wrote:

> A conforming RDFa Processor must not use the value of @version  to
> effect its processing. [WHAT MECHANISM IS RECOMMENDED BY THE WG
> INSTEAD? THE PREFERRED VERSIONING MECHANISM REMAINS UNCLEAR.]

We discussed this on a call a long time ago. Can't remember the outcome
of it, but I've always thought this should be a SHOULD NOT. Reason...
the above prohibition appears to make this illegal (in weird XML
pseudo-code):

	<BEGIN what="RDFa 1.1 Parser">
		<IF version="1.0">
			<SWITCH-TO what="RDFa 1.0 Parser" />
		</IF>
		<ELSE>
			<DO what="process using RDFa 1.1 rules" />
		</ELSE>
	</BEGIN>

But it does not forbid the following (and I don't think we could forbid
it):

	<BEGIN what="General Semantic XHTML Parser">
		<IF version="1.0">
			<SWITCH-TO what="RDFa 1.0 Parser" />
		</IF>
		<ELSE>
			<SWITCH-TO what="RDFa 1.1 Parser" />
		</ELSE>
	</BEGIN>

Even though the externally observable behaviour of each system is the
same. 

That is, if people want to use @version to do version detection, then
they can. And even if we say they MUST NOT do it as part of a
conforming RDFa 1.1 processor, they can work around the prohibition by
simply moving the version check outside the RDFa 1.1 processor, and
remain conforming.

For what it's worth, my RDFa parser supports 1.0 and 1.1, and also has
a "guess" mode that checks @version. I'd certainly claim this is
conforming - the RDFa 1.1 parser totally ignores @version; it's only
the "guess" parser that looks at it.

-- 
Toby A Inkster
<mailto:mail@tobyinkster.co.uk>
<http://tobyinkster.co.uk>
Received on Friday, 29 October 2010 21:48:24 UTC

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