W3C home > Mailing lists > Public > public-html@w3.org > May 2009

Re: RDFa in HTML 5

From: Sam Ruby <rubys@intertwingly.net>
Date: Sat, 23 May 2009 06:38:46 -0400
Message-ID: <4A17D236.4030701@intertwingly.net>
To: Manu Sporny <msporny@digitalbazaar.com>
CC: Philip Taylor <pjt47@cam.ac.uk>, RDFa mailing list <public-rdf-in-xhtml-tf@w3.org>, HTML WG <public-html@w3.org>
Manu Sporny wrote:
> Philip Taylor wrote:
>> As an attempt to clarify my current views
> Hi Philip, thanks for the set of clarifications and for your RDFa in
> HTML5 document. What follows is a general list of comments on your
> document. They are not complete, just notes on the approach that you
> have taken. I do realize that you didn't intend the proposal to be
> complete, but it does raise some issues that are concerning:
> * If my read on Sam, Shelley, Philip, the RDFa TF and the RDFa community
> is correct - all of us want a version of RDFa spec'ed for HTML.

I wish to enable those that wish to author such a document an 
opportunity to do so, and I wish to assist with the evaluation of consensus.

I will go further and say that if such markup is going to be widely 
deployed, and if there is tooling created to process this markup -- and 
both of these appear to already be true -- then it would be helpful if 
there was a spec.

> * All of us want RDFa spec'ed for HTML4, in some form.

Makes sense to me.  As you say below, "There should be one set of 
processing rules for all HTML family languages, if possible".

> * Some of us (in the RDFa TF, WHATWG, HTMLWG and RDFa community) want it
> spec'ed for HTML5 - others feel that Ian has already made up his mind
> about excluding RDFa (otherwise he would not have gone to the trouble to
> create the microdata proposal).

I believe it is fair to observe that Ian has evaluated RDFa and has, to 
date, chosen not to author or contribute to such a document.

Has anybody polled Dave Raggett, Arnaud Le Hors, or Ian Jacobs for their 
opinion on RDFa for HTML4?  Isn't the spec for RDFa in XHTML a separate 
document from the XHTML specs?

If it turns out that the the spec text is written, and that the 
consensus is that right place for such is in the HTML5 spec itself, and 
it turns out that Ian doesn't respect such consensus, then I am 
committed to resolve that problem.  But for now, I am not convinced that 
such spec text will be written, or that the consensus will be that 
inside the HTML5 spec is the right place for this text, or that Ian 
won't respect consensus.  Yes, Ian has said that his work will never use 
a consensus approach... as long as he is the editor.  If it comes to 
that, Chris, I, and PLH will deal with the situation.  But none of this 
should be preventing the questions that Philip asked on May 14th[1] from 
being acknowledged and addressed.

One last point: if XHTML1 and XHTML2 were deprecated in favor of XHTML5, 
then /perhaps/ inside the [X]HTML 5 spec /might/ be the right place for 
the definition of the "one set of processing rules for all HTML family 
languages", but again, I am not convinced that this is going to happen.

> * We want this to be a transparent, inclusive process that involves
> anybody that wants to be involved in the creation of an RDFa in HTML spec.


> * Philip may or may not be willing to work on the HTML5+RDFa spec - his
> level of interest in moving forward with this is hard to read. There has
> been no commitment from him to complete a full HTML5+RDFa spec.
> * Shelley seems to be interested in working on the HTML5+RDFa spec, but
> only in a supporting role. I'm interested in working on any version of
> an RDFa spec in HTML. Shane has produced a good first draft for RDFa in
> HTML4.

Shane's document is definitely a promising start.  It, however, does not 
address the questions that Philip posted on 14 May[1], nor has anybody 
stepped forward to answer such questions.  My read is that Philip posted 
a spec as a means to foster discussion, which again has failed to 
materialize.  My intuition is that the way that Philip can best assist 
is in the creation of evil test cases.  He appears to have a knack for 
that -- he has broken my weblog a number of times, something for which I 
continue to be grateful.

I do believe that Shelley will participate, but I also believe that 
there will be issues (e.g. the addressing of the types of questions that 
Philip is likely to raise) for which there are people with more specific 
expertise in these areas and such people would be better able to address 
them.  Shelley is not interested in getting in their way should they 
decide to openly participate.

> * There are concerns that if we go too crazy in these supplemental
> documents with re-defining things that don't need to be redefined, we
> will accidentally fragment RDFa. If we push this stuff out too soon,
> before it is ready, we could create fragmentation.

I am concerned that people are "going too crazy" in deploying both 
content and tooling without a proper definition, and that inevitably 
means that fragmentation has already occurred, and the longer the proper 
documentation is lacking, the greater the fragmentation will be and the 
harder it will be to address.

Am I unique in having this concern?

> * Philip's document starts this fragmentation process by re-defining
> CURIEs and the RDFa processing rules - which many agree is a very bad
> thing, even though we like the concept of a HTML5+RDFa document.

I am confident that Philip will agree that the important thing is that 
the questions he posed on 14 May[1] be addressed by any such document, 
and that the document he produced was a totally unofficial unfinished 
and experimental very rough initial attempt to address such questions, 
and will be quickly discarded should something better materialize.

> * There should be one set of processing rules for all HTML family
> languages, if possible.


> * There is minor concern that somebody will snatch the core of the RDFa
> document, put "RDFa for XYZ", wipe all of contributors names as well as
> the W3C's name from it and publish it as something new. Philip did some
> of this (probably by accident), but it sets a very bad precedent and
> opens the door for numerous "RDFa in XYZ" documents with conflicting
> processing rules. If this is done, it will certainly harm adoption,
> parsing simplicity, and may create a situation where RDFa markup becomes
> ambiguous (which is one of the RDFa community's worst-case scenarios).

To my mind, there is a bigger concern that the types of questions that 
Philip raised on 14 May[1] are not being addressed.  If we get to the 
point that such questions are at least acknowledged promptly and then 
actively worked, I am confident that fragmentation will not occur.

> This is meant to be high-level, constructive feedback and is not meant
> to deter Philip, or anybody else, from proposing a way forward. I think
> it's great, and there are a others that agree with me, that he's helping
> to move this boulder forward by putting something together. We really
> want to work with a broad set of communities to get RDFa adopted into
> more markup languages.
> These concerns above are ones that I hope that others will take into
> account when working toward RDFa solutions.
> If we are to focus on a set of concepts moving forward, it should be
> that we will take the time to carefully draft a set of documents that
> ensure backward-compatibility, and no fragmentation of the standard
> while providing RDFa markup for all HTML family languages.

I continue to believe that if fragmentation is the biggest concern, then 
the ever widening gap between specification and deployment is the most 
important thing to be addressed at the moment.

Oh, and did I mention that the questions that Philip raised on 14 May[1] 
have yet to be acknowledged and do not appear to be actively or openly 

> -- manu

- Sam Ruby

[1] http://tinyurl.com/pcp3f8
Received on Saturday, 23 May 2009 10:39:31 UTC

This archive was generated by hypermail 2.4.0 : Saturday, 9 October 2021 18:44:47 UTC