Re: HTML+RDFa Heartbeat Draft publishing request

Hi Julian and Larry,

On Jan 13, 2010, at 2:08 AM, Julian Reschke wrote:

> Larry Masinter wrote:
>>> Feedback on the current draft would be appreciated:
>>> http://html5.digitalbazaar.com/specs/rdfa.html
>> Alas, this specification also fails to fit within the charter of  
>> the HTML working group also.
>> While it does supply a mechanism to permit
>> RDFa to be mixed into HTML documents, thus actually
>> addressing *one* of the examples given, the charter
>> encourages *a* mechanism for mixing independently
>> developed vocabularies.
>> (For those who need clarification: in English, the use
>> of the indefinite article "a" in "a mechanism, indicates
>> the singular: one, not "one or more" not "several" not
>> "one for each".)
>> The HTML+RDFa doesn't address how to mix any other
>> independently developed vocabulary into HTML documents --
>> not any of the other two examples given in the charter,
>> (ITS and Ruby) nor any others.
>> Do you think it is possible to use the method proposed
>> here for RDF to apply to any other vocabulary?
>> Could the Microdata vocabulary be put into a namespace
>> and then used through this extensibility mechanism?
>
> I agree with Larry -- the charter *clearly* doesn't ask for RDFa or  
> (similar extensions) to be added, but for an extension mechanism  
> that allows to add those.
>
> "The HTML WG is encouraged to provide a mechanism to permit  
> independently developed vocabularies such as Internationalization  
> Tag Set (ITS), Ruby, and RDFa to be mixed into HTML documents.  
> Whether this occurs through the extensibility mechanism of XML,  
> whether it is also allowed in the classic HTML serialization, and  
> whether it uses the DTD and Schema modularization techniques, is for  
> the HTML WG to determine."
>
> And no, this isn't *twisting* the charter (-> <http://krijnhoetmer.nl/irc-logs/whatwg/20100113#l-552 
> >), it's *reading* it.
>
> That being said, I'd like the W3C to work on metadata extensions for  
> HTML, and do not care particularly where it happens. We already  
> published RDFa-in-HTML, so I wouldn't object to Microdata as well,  
> as long as it remains clear that it has exactly the same status with  
> respect to document validity.


My take on the charter is different:

- I believe the key point is to provide some form of extensibility  
that allows independently developed vocabularies to be mixed in. I do  
not believe it is essential whether this is through exactly one  
underlying mechanism, or several that serve different sets of use  
cases. It's worth noting especially that we have some pre-existing  
extensibility mechanisms, including XML namespaces in the XML  
serialization only, class, rel and <meta>. These mechanisms have in  
fact been used to mix in additional vocabularies, though not the ones  
listed. I think it would be a suspect reading to infer that we can add  
only exactly one extensibility mechanism to the multiple that exist.  
Charters do not normally constrain the technical details of how a  
Working Group fulfills its requirements, therefore I believe we should  
read this provision broadly unless there is a clear indicator of  
intent for a very narrow reading.

- I believe ITS, Ruby, and RDFa are representative examples of some of  
the kinds of vocabularies we might consider, not an exhaustive list.  
Consider that the list is missing MathML and SVG, which I believe have  
been shown to be by far the most desired vocabularies to mix in with  
HTML.

- If you consider just the stated examples, it's not clear that a  
single extensibility mechanism can cover them all. ITS is a vocabulary  
in custom XML namespace. Ruby is a set of elements that are intended  
to be used directly in the HTML namespace - they do not have a  
namespace of their own. They also need to plug into the content model  
in a very specific way. RDFa is a set of non-namespaced attributes  
that can go on any element in any namespace, plus reliance on at least  
the surface syntax of xml: namespace prefix declarations. Thus, if we  
add a mechanism for additional specifications to add extra elements  
and attributes as valid (a mechanism which we in fact have), that  
could cover Ruby and RDFa, but would do nothing for ITS. If we had a  
mechanism to use elements and attributes in custom XML-like  
namespaces, that would help ITS but would not be sufficient for Ruby  
or RDFa, without also allowing extensions in the HTML namespace (or in  
null-namespace attributes for elements in the HTML namespace). Thus,  
if you take the most literal reading of exactly one mechanism that  
covers exactly these three vocabularies, the requirement appears to be  
possibly unimplementable. I believe that when the charter is  
potentially ambiguous, it should be interpreted to avoid readings that  
lead to silly results (like impossible requirements).

- The matter is somewhat confused by the fact that RDFa is both an  
independently developed vocabulary in itself, *and* a mechanism for  
mixing in further independently developed vocabularies. Indeed, its  
whole reason for being is to allow mixing in of custom data  
vocabularies. Thus, we have both provided a mechanism to add RDFa (the  
"other applicable specifications" extension point) in narrow  
fulfillment of the charter, *and* we have fulfilled more of the  
broader spirit of the charter by producing an HTML+RDFa spec that  
takes advantage of this extension point to allow mixing in of even  
more additional vocabularies.

- The previous point applies to Microdata as well, except that it was  
not mentioned by name in the spec. It is both an extension and a  
mechanism for more extensions.


Thus my own reading would conclude:

- It is acceptable for us to use any number of fundamental extension  
mechanisms to provide for mixing in additional vocabularies, if that  
seems like the technically sound approach. We should not be struggling  
to shoehorn every kind of extension vocabulary into a single mechanism.
- We should be interested in allowing for all sorts of vocabularies,  
not just the three examples.
- We should not thrown by the fact that an extension can add further  
extension mechanisms.


Julian, Larry, and others who have charter concerns, if you are not  
persuaded by the above alone, we can take steps to get a more official  
interpretation. My understanding is that when there is disagreement on  
charter scope, a common procedure is that the Chairs confer with the  
Team Contacts on what is the most appropriate interpretation,  
considering both the language of the charter and the W3C Team's  
intent. Then they issue a ruling on interpretation of the charter,  
which can be appealed via the usual avenues (up to and including  
Formal Objection if necessary). So if anyone wishes to pursue the  
charter issue further, I can ask my co-Chairs and the Team Contacts to  
discuss this issue and enter our official interpretation.


Regards,
Maciej

Received on Wednesday, 13 January 2010 15:48:48 UTC