W3C home > Mailing lists > Public > public-rdf-in-xhtml-tf@w3.org > June 2009

Re: PROPOSED test cases 0127 and 0128 - empty xmlns attribute values

From: Shane McCarron <shane@aptest.com>
Date: Thu, 04 Jun 2009 20:14:02 -0500
Message-ID: <4A28715A.7050300@aptest.com>
To: Philip Taylor <pjt47@cam.ac.uk>
CC: "public-rdf-in-xhtml-tf.w3.org" <public-rdf-in-xhtml-tf@w3.org>

Philip Taylor wrote:
> Empty values for namespace prefix declarations are a well-formedness 
> error in all XML parsers that I'm aware of, so this document should 
> cause a fatal error (and no triples) in any RDFa-in-XML parser.
Hrm...... I strongly disagree.   RDFa in XHTML defines, in clause 4.3, 
RDFa Processor Conformance.  Such a processor, in the context of XHTML, 
is an XML Application - not an XML parser.  It is not up to an RDFa 
Processor *at all* to raise a fatal error when it encounters a 
well-formedness error.  It *might* be up to the underlying XML parser, 
but I don't know if it is really a requirement that there be a fatal 
error in this case.

This really comes down to something that has been discussed a few times, 
but perhaps not state clearly enough...  The architecture of RDFa, and 
in particular an RDFa Processor, exists independent of the underlying 
parsing model for the input - at least conceptually.  There may be 
requirements on these underlying parsers (XML well-formedness, HTML 5 
parsing rules, tag soup rules, etc.), but those requirements are imposed 
on the input stream BEFORE that stream is seen by an RDFa Processor.  In 
my mind, this is true regardless of whether the RDFa Processor is a 
component of a tool chain or a free standing implementation.  The RDFa 
Syntax Recommendation makes no representation about how the input is 

Mark, Ralph, Steven - what's your opinion?

Shane P. McCarron                          Phone: +1 763 786-8160 x120
Managing Director                            Fax: +1 763 786-8180
ApTest Minnesota                            Inet: shane@aptest.com
Received on Friday, 5 June 2009 01:14:50 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 21:50:32 UTC