Review comments on HTML+RDFa (was Re: FPWD Review Request: HTML+RDFa)

(Chair hat off, personal review comments only.)

On Sep 1, 2009, at 2:07 PM, Manu Sporny wrote:

> This is a request for HTML Working Group review of the HTML+RDFa
> specification in preparation for publishing it as a FPWD document.
>
> This is a companion document to the HTML5 specification.
>
> Standalone RDFa specification (FPWD candidate)
> ----------------------------------------------
> I've updated the previously published standalone RDFa specification to
> remove all issues and reflect current consensus in the RDFa community.
> This version asserts that xmlns: should be preserved in non-XML HTML5
> documents (DOMs) and any attribute starting with "xmlns:" should not
> raise validation warnings/errors. This version also asserts that
> "profile" should be a reserved keyword for use in <link rel="profile"
> href="http://www.w3.org/1999/xhtml/vocab" />.
>
> http://html5.digitalbazaar.com/specs/rdfa.html
>
> E-mail reviews can be sent to this mailing list, or the RDFa Task  
> Force
> mailing list (cc'ed).

Despite having some concerns about the design of RDFa, I think it is  
better to specify its use in text/html than not, and a separate spec  
seems like a good way to do so. So I support this effort.

Some review comments:

Status of this Document:

- It seems like this sentence is no longer accurate as to the intent:
"This specification is intended to be included in the HTML5  
specification as a section of the overall specification."

2 Parsing model:

- The normativity of this section is not stated.
- The language here seems vague. It seems to me that the mapping from  
the DOM to the RDFa processing model's abstract tree should be  
precisely defined.

3.1 Document Conformance:

- The Document Conformance requirements strike me as odd. They do not  
incorporate the full HTML5 conformance requirements (with appropriate  
extensions) or any of the RDFa conformance requirements, and the  
motivation for the specific requirements is unclear. The only MUST  
requirement is having a conforming HTML5 root element. It seems odd to  
call a document that only meets this one condition a "conforming HTML 
+RDFa document".

3.2 User Agent Conformance

- "excluding those features which are specifically overridden by this  
specification" it might be useful to list these.

4 Modifications to XHTML+RDFa

- Are these modifications intended to apply only to the HTML  
serialization of HTML5? That seems like the intent but it's not  
totally clear from me.
- One concern I have with only applying the changes to HTML: what if  
an RDFa processor has a parsed DOM, but does not know if the DOM was  
originally created from parsing HTML or XML? It would be better if a  
single set of rules could be used once you have a DOM, without having  
to know what kind it is, since the DOM itself does not directly expose  
that information.

4.2 Invalid XMLLiteral values

- Do XMLiteral values only need to be well-formed, or do they need to  
be namespace well-formed?

4.3 The xmlns: attribute

- This section seems to lack technical precision. Some specific points:
    - There's no such thing as "the xmlns: attribute"; xmlns is a  
predefined namespace prefix, not an attribute at all
    - "CURIE prefix mappings specified using xmlns:" does not clearly  
specify how attributes starting with xmlns: turn into prefix mappings.  
The processing model for this should be defined precisely.
    - The reference to [Namespaces in XML] doesn't really help,  
because it defines how namespace declarations work in XML only, and  
does not have anything to say about HTML or CURIEs for that matter.
    - Attributes starting with xmlns: will look different in HTML and  
XML DOMs, and perhaps different still when created with DOM API calls,  
the text should take account of this.

5 Modifications to HTML5

- I think it would be more accurate to say "Extensions to HTML5 syntax".

5.1 Preservation of the profile keyword

- I'd suggest renaming this "The profile link type"; unknown rel  
values are not dropped from the DOM, so there's nothing to preserve;  
the change is adding an additional conformance link type.
- I'd suggest restating the sentence to say something like "for  
content conforming to this specification, profile is a conforming link  
type.
- I'd suggest adding a table row that matches the table in HTML5  
Section 6.12.3 Link types to define all the needed info.

5.2 Preservation and Validation of xmlns:

- I suggest changing the section header to "Attributes that start with  
xmlns:"
- The requirement to preserve attributes starting with "xmlns:" is  
redundant with what HTML5 already requires. I suggest changing it to  
an informative note that HTML5 parsing will have this result, or  
striking that requirement entirely.
- The change should be stated as a conformance change instead of a  
requirement for validators not to generate warnings (they will in fact  
generate errors, not warnings in text/html). Something like: "For  
documents conforming to this specification, attributes with names that  
have the case insensitive prefix 'xmlns:' are conforming."
- Which attribute names starting with 'xmlns:' are conforming - all of  
them? Even ones in uppercase or mixed case? Even ones that are not  
namespace-well-formed XML namespace declarations? Even ones that would  
trigger strange error behavior in text/html parsing? I think there  
actually needs to be a specific syntax for the additional attributes  
that are allowed, and it should be defined here. Then the spec can say  
that attributes with names matching that syntax are conforming.
- There should probably also be a requirement that the attribute value  
is whatever Namespaces in XML allows as values for namespace  
declarations

General comments:

- I found it very hard to follow this document, since it seems to  
assume full knowledge of RDFa in XHTML and only defines a delta. As a  
result:
    - It was hard for me to understand the actual processing model, so  
that I'd understand what I had to do as an implementor.
    - I had no notion of the syntax, so I wouldn't know what to do as  
an author.
    - As a reviewer, it was impossible for me to determine if the  
processing requirements were precisely specified, free of  
contradictions and sane.

- There have been some discussions of some modest extensions to RDFa  
to allow cleaner use in text/html in a way that allows DOM consistency  
between text/html and XML. For example, there was the idea to use a  
"prefix" attribute instead of xmlns: declarations to define CURIE  
prefixes, and also the idea to allow full URIs as an alternative to  
CURIEs. Have these ideas been rejected?


Regards,
Maciej