Re: Publishing a new draft (HTML5+RDFa)

On Fri, Jul 31, 2009 at 9:18 AM, Ben Adida<ben@adida.net> wrote:
> Ian Hickson wrote:
>> By "technical problems" I mean problems with the design, as opposed to
>> editorial problems. They're primarily usability issues, which are to some
>> extent subjective. I make no apology for having an opinion on what makes a
>> usable language; it's my job to have such an opinion.
>
> Of course you have an opinion, we all do.
>
> But it's time to stop couching your personal opinion as objective
> "technical problems." If RDFa were impossible to parse in today's
> browsers with today's JavaScript, that would be an objective technical
> problem. If no one could get RDFa markup right, that would be an
> objective technical problem. Clearly, the evidence shows that people are
> marking up pages with RDFa just fine, and people are parsing RDFa just fine.

I personally would like the bar to be placed higher than simply
"impossible" or that "no one could get EDFa markup right". If
something is sufficiently hard, but still possible, then I think that
could be grounds for rejection from HTML5.

I too have the perception that RDFa is overly complex for the use
cases presented to the HTML WG. I have seen people claim that the use
cases RDFa was designed to solve necessitates the current complexity.
This could very well be the case, but so far none of the use cases
presented to the HTML WG has seemed to necessitate the same level of
complexity.

(As an aside, I also wonder if maybe the use cases that necessitated
for example the need for arbitrary graphs, rather than simply trees,
are really worth the added complexity. I.e. if you can remove a
significant amount of complexity, while only loosing a few use cases,
then it could very well be worth not solving those use cases. This is
definitely a judgment call that needs to be done on a case by case
basis though)

As a counter example, I believe that HTML5 parsing is way too complex.
However one of the requirements that we've had is that HTML5 parsing
should be compatible with HTML pages that exist on the web today. This
has necessitated the current, very complex, algorithm. However, even
here there are judgment calls and personal preferences. For example if
we can reduce complexity by becoming incompatible with a small number
of pages, it might well be worth doing so, and I believe we have made
that decision on occasion.

> In other words, the *only reason* that micro-data is in the HTML5 spec
> and not RDFa is because of your personal preference.

I believe Ian laid out solid arguments for why microdata has some
technical advantages over RDFa in his initial microdata proposal, so
it is clear to me that both alternatives should be considered and
evaluated. Further I have heard several people on this list express
liking for microdata. So while I agree it's personal preferences that
decides how strongly to value the various technical
advantages/disadvantages with the two proposal, it is clear to me that
it's not just Ians personal preferences that is currently keeping it
in the spec.

For what it's worth Maciej wrote a very good summary for why the use
of prefixes in RDFa is a technical disadvantage (again, how strongly
to value that is a separate issue).

> But this is a W3C working group. It should function on consensus. One
> person's opinion does not a spec make, even when that person is someone
> like you, Ian, who's contributed an incredible amount of work to the
> HTML effort.
>
> If you won't agree to consensus for "your" version of the spec, then the
> WG must allow other versions to be published in parallel, so that
> consensus might emerge from competing views.

100% Agreed.

/ Jonas

Received on Wednesday, 5 August 2009 17:54:45 UTC