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

Henri Sivonen wrote:
>
> How would you characterize the ongoing denial that the syntax 
> xmlns:p="http://example.com/" is problematic?
> http://lists.w3.org/Archives/Public/public-html/2009Sep/0843.html
> http://lists.w3.org/Archives/Public/public-html/2009Sep/0790.html
>
> How can the problem be meaningfully resolved when you aren't even 
> admitting there's a problem to discuss?
Because, Henri, we don't grok the problem.  I am slowly beginning to 
understand that this might be due to our talking past one another.  The 
W3C has a Recommendation that defines the Syntax of RDFa *input* and the 
extraction of RDF triples from that *input*.  It defines this as an 
extension to XHTML.   XHTML Modularization provides the structure for a 
host language.  The Recommendation is carefully vague about how that 
input is parsed because that is properly the job of the host language.

In the RDFa in HTML document, Manu has deferred the syntax and 
extraction to the existing Recommendation, and has deferred the parsing 
of the input to the host language specification (HTML5). 

Jonas, Maciej, and you have pointed out that (my translation here) since 
it is possible for the *input* to be altered on its way to the code that 
would perform the extraction, it is important we define the rules for 
that extraction more tightly.  In particular, it is possible that the 
syntax of an 'xmlns:' declaration attribute may not be readily 
available.  It is also possible that, depending on the form of the 
*input* document, the declaration attribute may manifest in different 
ways on its way through the toolchain (e.g., showing up as a literal 
'xmlns:foo' in HTML mode, and as 'foo' in the XMLNS namespace in XML 
mode).  However, I don't think *anyone* has said that the declaration 
will not be present in some form if it was present in the original 
*input*.  And that's how the processing rules are written.

Section 5.5 defines the way in which prefix mappings are defined and 
remembered by an implementation, not how they are pulled from the data 
stream by that implementation.  To the RDFa Task Force, these are 
implementation details.  Depending upon your implementation strategy and 
environment, you will need to find the things the RDFa extraction 
process cares about, and act upon them to generate the triples.  We 
really, really, really don't care how you do this.  What we care about 
is that each engine emits the same triples in the end.  That's why there 
is a test suite, and its why there were lots of independent 
implementations with completely different strategies long before the 
specification was complete.

Regardless, I agree there is room to tighten the language to ensure that 
implementors have the proper guidance, and that edge conditions, even 
pathological ones, have clear, consistent rules.  I have proposed that 
we augment the text in RDFa Syntax section 5.5 step 2 to directly 
address this problem, and am updating my proposed errata text now.  I 
hope that, when that is ready, you will continue to help by letting us 
know if it satisfies your objections.

Thanks!

-- 
Shane P. McCarron                          Phone: +1 763 786-8160 x120
Managing Director                            Fax: +1 763 786-8180
ApTest Minnesota                            Inet: shane@aptest.com

Received on Tuesday, 22 September 2009 16:49:05 UTC