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

Maciej Stachowiak wrote:
> (Chair hat off, personal review comments only.)

Thanks for reviewing the HTML5+RDFa FPWD candidate Maciej, your time is
appreciated. :)

Your comments, as well as Leif's comments, have been noted on the RDFa wiki:

http://rdfa.info/wiki/Html5-rdfa-wd-issues

We'll work through them as the weeks go on. I agree with a good amount
of what you have to say, so the only items that are replied to below are
ones that either need more clarification or provide clarification.
Assume that the rest of your statements will be met with some type of
re-wording or update to the HTML5+RDFa spec.

> 4 Modifications to XHTML+RDFa
> - 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?

Hmm... that shouldn't matter. What made you think it does matter?

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

This was the intent of the section, what made you think that the rules
for an XHTML DOM and an HTML DOM were different?

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

I believe the current consensus is that they just need to be
well-formed. Did you have a technical reason why they should be one over
the other?

> 4.3 The xmlns: attribute
>    - "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 processing rules for converting xmlns: to prefix mappings are
outlined in the XHTML+RDFa spec, Section 5.5:

http://www.w3.org/TR/rdfa-syntax/#sec_5.5.

Is that sufficient? If not, why not?

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

That's correct, this spec does require full knowledge of XHTML+RDFa. The
document attempts to not duplicate normative content between XHTML+RDFa
and HTML5+RDFa specifications. There are very few changes needed to put
RDFa into HTML5, so we didn't see a need to re-state large sections of
the RDFa specification in this document. By duplicating the XHTML+RDFa
REC language, we create a mechanism where we unnecessarily duplicate
content at best, and at worst, we could accidentally deviate from the
pre-existing RDFa REC language (and the test suite).

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

The processing model is the exact same as XHTML+RDFa, except for section
4.1 and 4.2 in the HTML5+RDFa document. Would expressing which steps
section 4.1 and 4.2 refer to in the XHTML+RDFa document be beneficial?

> - I had no notion of the syntax, so I wouldn't know what to do as an
> author.

The syntax is covered in detail in the XHTML+RDFa Syntax and
Processing[1] document as well as the RDFa Primer[2] document. Are these
not sufficient?

>    - As a reviewer, it was impossible for me to determine if the
> processing requirements were precisely specified, free of contradictions
> and sane.

Would making the changes you listed help alleviate this issue?

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

Neither idea has been rejected. We're still discussing @prefix, but we
cannot add it to XHTML+RDFa without performing a revision of the
specification -- including the usual LC->REC process.

@prefix is part of a larger set of changes that may be realized in RDFa
1.1 (the next version of RDFa, which we hope will unify RDFa expression
in both HTML and XHTML). We hope that RDFa 1.1 will replace the current
XHTML+RDFa and HTML5+RDFa FPWD with one specification document. Hence,
why I personally think it would be better to have RDFa defined outside
of the HTML5 specification than inside.

We discussed full URI support in @rel/@rev/@property/@resource, and
there is a technical solution that would allow it to happen, but it was
met with some pushback in the RDFa community. I prefer to have this
supported in RDFa, but we haven't attempted to gather consensus around
the feature and probably won't until RDFa 1.1.

RDFa 1.1 could also have a mechanism to extend the set of keywords,
allowing more Microformats-like property names (that map to URIs), but
again... that's a feature that may not be standardized for another year
or so and would require a full LC->REC process.

-- manu

[1]http://www.w3.org/TR/rdfa-syntax/
[2]http://www.w3.org/TR/xhtml-rdfa-primer/

-- 
Manu Sporny (skype: msporny, twitter: manusporny)
President/CEO - Digital Bazaar, Inc.
blog: The Pirate Bay and Building an Equitable Culture
http://blog.digitalbazaar.com/2009/08/30/equitable-culture/

Received on Wednesday, 2 September 2009 04:21:38 UTC