Re: RDFa in HTML 5

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

Sam, I'm not sure that I agree with XHTML1 or 2 being deprecated in 
favor of XHTML5. I do not believe that XHTML5 has actually been defined 
well enough to make this so. In fact the thought of such deprecation 
fills me with alarm. But that's not necessarily relevant to this 
discussion.

Unlike SVG and MathML, which needed a place in the document in order to 
encourage their support in HTML by the browsers, RDFa doesn't 
necessarily need to be handled by the browser companies. They can choose 
to do something with the RDFa, but there isn't the necessity of support. 
Well other than not throwing errors, and allowing the attributes to be 
part of the DOM. They do this now, though.

One issue related to the DOM is the use of namespaces and CURIE. 
Specifically how browsers handle these differently with HTML and XHTML. 
However, if the purpose of the HTML5 document is also to address changes 
to the DOM, then I don't see why these differences can't be handled 
within the HTML5 document, and perhaps this is the section that _really_ 
needs to get added to the HTML5 spec. It is really this, not RDFa that 
underlies Ian's resistance.


>> * 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.
>
> +1
>
>> * 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.
>
I can also attest to Philip's evil genius in breaking web pages in a 
XHTML web site. I'm actually redesigning my comment system with Philip 
in mind.

My concern about being an author is based on two things:

The HTML5 folks have expressed reservations about my not being able to 
help create a document that would be integrated gracefully into the 
document. That I don't have the experience, and it would take me too 
long to get the experience. Actually the discussion was that most people 
interested in RDFa would lack the experience. This is a fair concern, as 
our interests are focused.

Secondly, I don't consider myself an expert in RDFa. For years, I 
favored the use of RDF/XML and a separate document. Now, though, I can 
see the benefits of embedded metadata, especially with my use of Drupal 
for my site implementations. But I am new to the use of RDFa.

However, I'd still be willing to write a section in the document, 
ensuring that RDFa is supported, with the help of RDFa folks and HTML5 
folks, but I still believe that the real issue is namespace support. 
Namespace and support for some attributes that would most likely go 
beyond RDFa's necessity for these attributes. But, my main focus right 
now is working to prove the lack of viability for the microdata section, 
including the predefined vocabularies.

As for your concerns about nothing being written, people have been 
writing documents. They write them based on their own view of what's 
necessary, and there's not a lot of reach between the HTML5 interests 
and the RDFa folks interests. Again, though, I believe this is because 
we shouldn't be working to insert something specific to RDFa into the 
HTML5 document, but sections that address those aspects of RDFa that 
need to be supported into the future.

But this is just my opinion.
>> * 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.
>
+1
> 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.
>
I'm not going to speak to Philip's intentions, but I think the 
unanswered questions that Philip posed is symptomatic of the underlying 
problems -- we can write all we want, but if all that results is folks 
tossing documents at each other at 20 paces, all we're doing is filling 
email lists with cruft.

I think a commitment from members of both groups is necessary before 
anything else is done.  But a good hard look at what's really needed to 
ensure that RDFa in HTML5 should be made before we shove yet another 
section into a document that's already a bit bloated.

>> * There should be one set of processing rules for all HTML family
>> languages, if possible.
>
> +1
>
>> * 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.
>
I think that Manu's concerns are valid. I believe that answering 
Philip's questions are important, but not the end all or be all of 
moving forward. I'm also extremely concerned about how willing the HTML5 
folks are to generate multiple sets of rules for processing what should 
be the same data. This speaks an emphasis on process over data. I think 
the most important thing to happen, first, is that the HTML5 folks agree 
with an underlying concept: that there is one set of rules for 
processing the data, AND that the HTML5 folks aren't necessarily the 
best to derive those rules.

>> 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 worked?
>
Over mentioned, but I think your concerns also have merit, Sam.

The point is, the HTML5 specification is moving forward relatively 
quickly to Last Call. As it stands right now, I believe sections of it 
would be harmful to RDFa/RDF. I also believe the same sections would be 
harmful to microformats, and the web in general. But addressing these 
concerns is only part of the equation. Perhaps the other part of the 
equation is just coming to an agreement about whether RDFa has to be 
specifically included in the HTML5 spec, or if there are only specific 
aspects of RDFa that aren't unique to RDFa that need to be addressed in 
the document. If it's the latter, than these the areas that should have 
priority, and perhaps an overall RDFa in X/HTML document can come at a 
later time.


>> -- manu
>
> - Sam Ruby
>
> [1] http://tinyurl.com/pcp3f8
>
>

Shelley

Received on Saturday, 23 May 2009 11:30:31 UTC