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

Maciej Stachowiak wrote:
> A further issue I noticed:
>
> HTML+RDFa extends HTML5 by making <link rel="profile"> and xmlns:*
> attributes conforming (that seems to be the intent at least). But it
> does not seem to make @rev, @content, @about, @property, @resource, '
> @datatype or @object conforming or define their conforming values in
> HTML5.

Did you mean @object or @typeof?

> It also does not make CURIEs allowed rel values in HTML5. Thus,
> it does not seem to actually make RDFa syntax legal for text/html
> documents.

Hmm, I see your point. The intent was to make RDFa syntax legal by
referring to the XHTML+RDFa specification. @rev, @content, @about,
@property, @resource, @datatype, and @typeof as well as the valid CURIE
rel values should be conformant.

A balance must be struck between being very clear in the HTML+RDFa
specification and duplicating as little information as possible (if any)
from the XHTML+RDFa specification.

Would informatively referring to the attributes and rel values help? Or
would you prefer that normative language is specified (which is
problematic because we start duplicating information between XHTML+RDFa
and HTML+RDFa).

SVG Tiny 1.2 incorporates RDFa by reference, but adds some normative
text to ensure that each attribute is intended to be functionally
compatible with the intent of the XHTML+RDFa spec. Would adding
normative language like that in the SVG 1.2 spec address the issue?

http://www.w3.org/TR/SVGTiny12/single-page.html#metadata-MetadataAttributes

Smylers wrote:
>>> - 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.
> 
> That's unfortunate for those familiar with HTML 5 but unfamilar with
> RDFa or XHTML, putting an extra dependency on learning and evaluating
> this stuff.

Whether the normative text is a combination of the XHTML+RDFa and
HTML+RDFa specs, or whether it is a single document, the amount of text
one must read to become familiar with RDFa is still the same. Reading
both the XHTML+RDFa and HTML+RDFa specs are necessary to understand the
technology -- that is the cost of having a clear specification on RDFa
(with a complete test suite and many implementations).

If you have another suggestion on how this could be accomplished, please
let me know.

>> The document attempts to not duplicate normative content between
>> XHTML+RDFa and HTML5+RDFa specifications.
> 
> Lack of duplication is obviously good, however it may be that some
> refactoring could avoid both the duplication and the seemingly
> irrelevant dependency: put the common parts in a third specfication, and
> have t'other two depend on it.

The long-term goal is to create a unified spec in RDFa 1.1, which would
replace XHTML+RDFa and HTML+RDFa... but that specification is a long way
off. Our short-term primary goal is to ensure that RDFa is clearly
defined for all XHTML/HTML family languages first, before iterating the
entire specification, adding features, or refactoring the specifications.

> But in this particular case I don't think that's necessary.  The
> existing XHTML+RDFa specifcation applies to XHTML1.1.  The HTML5 spec
> will, when published, supersede XHTML1.1, defining XHTML5 as the current
> version of XHTML.  It would seem very odd for using RDFa in HTML5 to
> have a dependency chain which involves a standard which HTML5 itself
> replaces; it keeps XHTML1.1 hanging around after it has supposedly been
> superseded.

I would hope that a future revision of RDFa (RDFa 1.1) would break this
dependency and unify RDFa representation between XHTML and HTML by using
lessons learned by publishing the current HTML+RDFa spec.

While the specification dependency on XHTML 1.1 of XHTML+RDFa is a valid
point, I don't see what sort of technical issue this causes for RDFa
Processors? Since XHTML5 supersedes XHTML 1.1, and doesn't create any
technical changes that would prevent an RDFa processor from operating, I
don't see what technical harm would be done. Am I missing something?

This seems to be a "specification lawyering issue" (and I use that term
in a very positive light, not a negative one) rather than an actual
technical issue.

> HTML5 does "duplicate" information which is also covered by HTML4 and
> XHTML1, since it is intended to replace them.  Once that has happened,
> HTML5 (with both its HTML and XHTML serializations) will be the only
> 'current' HTML, and the only one for which RDFa integration needs
> defining.

There will still be those that chose to publish using XHTML 1.1 -- and
RDFa will need to continue to be specified for that dialect as well.
However, we are confident that a single RDFa specification can target
HTML4, XHTML 1.1, HTML5 and XHTML5.

> So a standard which completely defines RDFa's use with HTML5 would
> indeed duplicate information from previous standards, but at the point
> of its (and HTML5's) publication those previous standards would have
> been superseded, so longer relevant.

I agree with your end-goal, as it is also the end-goal for the RDFa TF.
It's when and how we get there that I believe is being discussed. There
will certainly be another revision of RDFa, with some much-demanded
features and alterations, before the end of 2010. However, that doesn't
mean that we should wait until the end of 2010 in order to define a
clear WD specification for HTML5 and XHTML5.

-- manu

-- 
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 16:03:35 UTC