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

Re: Request to publish HTML+RDFa (draft 3) as FPWD

From: Maciej Stachowiak <mjs@apple.com>
Date: Mon, 21 Sep 2009 13:16:17 -0700
Cc: Jonas Sicking <jonas@sicking.cc>, Manu Sporny <msporny@digitalbazaar.com>, HTMLWG WG <public-html@w3.org>, RDFa mailing list <public-rdf-in-xhtml-tf@w3.org>
Message-id: <89D11DBE-448E-4585-9A7C-E9B3069FF09B@apple.com>
To: Shane McCarron <shane@aptest.com>

On Sep 21, 2009, at 12:21 PM, Shane McCarron wrote:

> Maciej,
>
> My comments below:
>
> Maciej Stachowiak wrote:
>>
>> On Sep 19, 2009, at 12:54 AM, Jonas Sicking wrote:
>>
>>>
>>> However as far as I can see the spec doesn't actually define how  
>>> to do
>>> prefix mapping in a DOM.
>>>
>>> Or am I missing something?
>>
>> You're not missing anything. It's not currently defined. This was  
>> one of my points of feedback on the initial draft, which Manu  
>> believed he addressed by citing section 5.4 of the XHTML+RDFa spec.  
>> But that section does not define anything about pseudo-namespace  
>> syntax in HTML. It's not even the section that defines the  
>> normative processing requirements for CURIE prefix mappings in XML  
>> - that would be 5.5. And the rules in 5.5 do not even correctly  
>> describe what should be done in XML, as explained by be here <http://lists.w3.org/Archives/Public/public-html/2009Sep/0089.html 
>> > (scroll down to Manu's mention of "Section 5.5" and my reply).
> Obviously, we disagree.  Section 5.4 clearly indicates a normative  
> requirement that prefixes are declared using the syntax as defined  
> in the Namespaces in XML Recommendation.  If you don't read it that  
> way, do you have a proposed change that we could fold into the  
> errata for the RDFa Syntax Recommendation?

Here is the only implementation conformance requirement regarding  
prefix mapping that I could find in section 5.4:

"Since CURIE mappings are created by authors via the XML namespace  
syntax [XMLNS] an RDFa processor MUST take into account the  
hierarchical nature of prefix declarations."

I do not think this is adequate to define the processing model,  
particularly not in a non-XML context. Indeed, this requirement  
appears to be redundant with what Section 5.5 says (or is trying to  
say, anyway), so I'm not sure why it is there at all.

Section 5.5 does define the processing model in some detail (modulo  
bugs). But even assuming the bugs are fixed, it does not define  
anything in the context of HTML as opposed to XML.

It would not be at all difficult to define this unambiguously in RDFa 
+HTML. Here is a sample attempt by me:

'When applying the processing rules of XHTML+RDFa section 5.5 to an  
HTML document, modify step 2 as follows. In addition to XML namespace  
declarations, attributes in no namespace that start with the string  
"xmlns:" create a namespace mapping if the attribute name matches the  
PrefixedName production from [Namespaces in XML]. For each such  
attribute, add a mapping to the [local list of URI mappings]; the  
value to be mapped is the attribute name with the first six characters  
(the initial "xmlns:") removed, and the value to map to is the  
attribute value.'

(Note: this allows proper namespace declarations added with namespace- 
aware DOM APIs to still work in HTML documents. If this is not  
desired, then simply replace "In addition to" with "Instead of".)

> As to your concern about section 5.5, thanks for bringing that to  
> our attention.  I proposed errata text to clarify that wording [1]  
> and I expect it to be approved at the next Task Force meeting.
>
> [1] http://lists.w3.org/Archives/Public/public-rdf-in-xhtml-tf/2009Sep/0092.html

I find that errata text a bit confusing. Here's a few issues I spotted:

1) Instead of "Mappings are provided via the PrefixedAttName  
production as defined in [XMLNS]," it should probably say "Mappings  
are provided by XML namespace declarations, excluding default  
namespace declarations, as defined in [XMLNS]". I say this because  
RDFa processing rules operate on an abstract tree model, and not at  
the raw textual level. If you want to use a grammar rule, you have to  
define what it applies to (the qualified name of the attribute I guess?)

2) The erratum text says: "The real meaning if this is only clear in  
the context of Section 5.4.1. Scoping of Prefix Mappings, which  
normatively includes the syntax processing rules of the Namespaces in  
XML Recommendation," but section 5.4.1 does not appear to do that. The  
only mention of XMLNS is in a factual dependent clause: "Since CURIE  
mappings are created by authors via the XML namespace syntax [XMLNS]",  
that precedes a conformance requirement to "take into account the  
hierarchical nature of prefix declarations". As far as I can tell,  
there is no conformance requirement to follow the syntax processing  
rules of Namespaces in XML in general. If such a requirement was  
intended, it should be stated clearly. Though personally, I think it's  
better to precisely define the exact processing rules in section 5.5,  
since Namespaces in XML is defined purely at a textual level, but RDFa  
processing is defined on an abstract tree model, so it's not  
necessarily obvious how to apply the rules.


>
>>
>> Needless to say, I am not satisfied that my comment on this has  
>> been addressed. It appears to me that the xmlns processing model  
>> for HTML remains totally undefined.
>
> There is no "xmlns" processing model in RDFa.  There is a syntax  
> specification and rules for extracting prefix mappings from that  
> syntax.  Both of those are normative, including by reference for  
> their relevant, defining Recommendations.

Namespaces in XML does not apply to HTML, it only defines grammar and  
processing rules for well-formed XML documents. So citing Namespaces  
in XML doesn't answer anything. It's like explaining UTF-8 by pointing  
to a spec for UTF-16 surrogate pairs.

It's really not very hard to define the processing rules in a clear an  
precise way. I gave an example for how to do it. This doesn't have a  
material effect on the intent of the spec, it just makes it unambiguous.

Regards,
Maciej
Received on Monday, 21 September 2009 20:16:59 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Monday, 21 September 2009 20:17:00 GMT