Re: Publishing a new draft (HTML5+RDFa)

On Jul 30, 2009, at 6:23 PM, Sam Ruby wrote:

> Maciej Stachowiak wrote:
>> On Jul 30, 2009, at 3:49 PM, Sam Ruby wrote:
>>> In at least two cases (declaring what Google, Yahoo!, CC and  
>>> others are doing with RDFa as non-conforming, and declaring what  
>>> JAWS and other tools support with the summary attribute as  
>>> obsolete) I see areas where I believe that intelligent people can  
>>> reasonably disagree.
>> The second part of that sentence is not an accurate reflection of  
>> what the spec says. It says that *using* the summary attribute is  
>> obsolete, and incurs a mandatory validator warning, but there's  
>> nothing obsolete about implementing it, as JAWS does.
>
> I still believe that this is an area where intelligent people can  
> reasonably disagree.
>
> It is theoretically possible to get all of the major browser vendors  
> in a room and get them to agree, and where the spec has documented  
> such agreement it is rock solid (yes, even in areas where it  
> disagrees with other specs).
>
> It is not possible to do the same exercise with authors, and where  
> the spec attempts to influence behavior through mandatory warnings,  
> particularly when those warnings disagree with the the  
> recommendations of others and cases where the behavior produces  
> observable behavior in tools like popular tools like JAWS (and, I  
> learned today that this attribute is specifically exposed through  
> Windows APIs to yet other tools)... lets just say that I fully  
> understand that this is an area where intelligent people can disagree.

People can certainly disagree, and indeed they do. I just wanted to  
make sure the point of disagreement was stated correctly. At this  
point, it's about authoring advice and warnings, not authoring  
requirements or implementation requirements. Which is considerably  
smaller stakes, especially since anyone is free to give their own  
alternative advice.

Further, while I think reasonable people can disagree with what the  
spec says, much of the disagreement so far has not been expressed in  
reasonable terms. I have seen a lot of grandstanding and not a lot of  
clear statements of what's wrong on a technical level with the spec's  
current approach (as opposed to the older spec where summary="" was  
nonconforming).

>
>> Here's an interesting side note: HTML5 actually has a hook for open- 
>> ended extension by other specs. <http://dev.w3.org/html5/spec/Overview.html#semantics-0 
>> > "Authors must not use elements, attributes, and attribute values  
>> that are not permitted by this specification or *other applicable  
>> specifications*." [emphasis mine]
>> While less formal than the XHTML Modularization mechanism, it seems  
>> to allow a specification external to HTML5 could define RDFa  
>> additions without also having to copy the full text of HTML5.  
>> Validators could then choose to support profiles that do or don't  
>> support RDFa, based on market demand. I think a draft that just  
>> defined the RDFa additions would engender less potential  
>> controversy than a full alternative draft of all of HTML5.
>
> I understand and agree with your overall point.
>
> I question why this is suggested for RDFa but not for micro-data.

I'm suggesting it as a way for someone interested in HTML5+RDFa to  
make it happen without having to edit the whole rest of the HTML spec  
or compete with anyone else's draft. That doesn't mean it's the only  
choice for how to proceed. But it is a choice that would, I think,  
achieve the goals of RDFa advocates with less potential for conflict.

In the abstract. think it would be reasonable to put microdata in a  
separate spec. And I believe it has in fact been suggested, though not  
specifically by me.

There are two relevant differences from the point of view of my  
suggestion: (1) Hixie is already editing the whole rest of the HTML  
spec so it wouldn't save him the work of maintaining the rest of the  
spec; and (2) microdata has conformance requirements for HTML  
implementations, not just authors, and some of those integrate in  
tighter ways than just adding new attributes.

Overall, this gives microdata a higher bar for success. It will fail  
if it doesn't get implementation traction in browsers, because  
unimplemented features will have to be dropped for HTML5 advance along  
the REC trac. But HTML5+RDFa by design would not need any browser- 
based implementation to advance.

Your questioning seemed to imply my suggestion suggestion might not be  
made in good faith. I think that is unwarranted. It seems that some WG  
participants are uncomfortable with a perception of forks or branches,  
and I've suggested a way to proceed that would appear less forky.

Unlike the case with the summary="" controversy, I think a technical  
case has been made for some spec soundly and precisely defining RDFa's  
use in text/html. Content producers are generating RDFa, and content  
consumers are processing it, so the state where there is no clear spec  
for such usage is on the whole detrimental. If these usage trends  
grow, then we will be stuck with the fun of reverse engineering de  
facto behavior in the future. That mistake has been made too many  
times already, in the history of the web platform. Probably the  
easiest path to a sound spec is to define it in terms of the DOM; this  
would build on HTML5 parsing for handling of the concrete syntax and  
would let the spec focus on unambiguous definition of the semantics.

Regards,
Maciej

Received on Friday, 31 July 2009 02:05:00 UTC