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: Philip Taylor <pjt47@cam.ac.uk>
Date: Fri, 05 Jun 2009 13:57:59 +0100
Message-ID: <4A291657.9020805@cam.ac.uk>
To: Shane McCarron <shane@aptest.com>
CC: "public-rdf-in-xhtml-tf.w3.org" <public-rdf-in-xhtml-tf@w3.org>
Shane McCarron wrote:
> 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, 
> [...]

Sorry, I was inaccurate in saying it would cause a fatal error in the 
RDFa-in-X(HT)ML parser. But I believe it's correct to say it would cause 
a fatal error in the XML parser (on top of which the RDFa processor is 
built as an application), and http://www.w3.org/TR/REC-xml/#dt-fatal says:

   "Once a fatal error is detected, however, the processor MUST NOT 
continue normal processing (i.e., it MUST NOT continue to pass character 
data and information about the document's logical structure to the 
application in the normal way)."

so the RDFa processor (when running as an XML application) won't see the 
logical structure of the rest of the document, and therefore won't be 
able to extract any triples that come after the error in the original 
document, which would change the expected output for these test cases.

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

I'm fairly sure it is:

http://www.w3.org/XML/2006/xml-names-errata says "In a namespace 
declaration for a prefix (i.e where the NSAttName is a PrefixedAttName), 
the attribute value MUST NOT be empty.", so the document with 
xmlns:foaf="" does not conform to the Namespaces specification.

http://www.w3.org/TR/REC-xml-names/ says "A document is 
namespace-well-formed if it conforms to this specification.", so the 
document is not namespace-well-formed.

It also says "a processor MUST report violations of namespace 
well-formedness", and http://www.w3.org/TR/REC-xml/ says "Violations of 
well-formedness constraints are fatal errors." -- the definitions are a 
little bit disconnected (I don't think it precisely states that 
namespace-well-formedness violations are fatal errors), but it's 
reasonable to interpret it as meaning namespace-ill-formedness is a 
fatal error and that's what every namespace-aware XML parser implements 
so it's close enough to true.

(http://www.w3.org/TR/xhtml-modularization/conformance.html#s_conform_user_agent 
doesn't seem to actually say that the UA must conform to the Namespaces 
in XML specification (it only refers to XML 1.0) -- I'm not sure if I'm 
missing something that says so, but anyway I'd hope it's obvious that it 
must.)

> The architecture of RDFa, and 
> in particular an RDFa Processor, exists independent of the underlying 
> parsing model for the input - at least conceptually.

As far as I'm aware these test cases are meant to be interpreted as 
XHTML 1.1 documents, and so XML (namespace-)well-formedness constraints 
are critical to the processing of the test cases, regardless of whether 
the RDFa processor could also be used in a different context with a 
different parsing model.

(The tests would be fine in a context where the documents are meant to 
be interpreted as something other than XML, e.g. as HTML 5 documents, in 
which case I agree with Mark that the RDFa processor shouldn't be 
expected to abort processing and that it raises the question of what the 
behaviour needs to be instead.)

-- 
Philip Taylor
pjt47@cam.ac.uk
Received on Friday, 5 June 2009 12:58:31 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Friday, 5 June 2009 12:58:32 GMT