[whatwg] Trying to work out the problems solved by RDFa

[Tab Atkins Jr.]

On Fri, Jan 2, 2009 at 12:02 PM, Julian Reschke <julian.reschke at gmx.de> wrote:
> Tab Atkins Jr. wrote:
>>>>
>>>> Right, but microformats can be used without any changes to the HTML
>>>> language, whereas RDFa requires such changes.  If they fulfill the same
>>>> use
>>>> cases, then there's not much point in adding RDFa.
>>>
>>> ...
>>
>> Why the non-response?  This is precisely the point of contention.
>> Things aren't added to the spec on a whim.  Things get added when it
>> is demonstrated that authors will significantly benefit from the
>> inclusion of the feature in the language.  Microformats (used as an
>> example only) use only features already in the language, and thus do
>> not need any spec support.  If they already solve the problem
>> adequately, then there is no need to go further.
>> ...
>
> I think the supporters of RDFa (me included) claim that Microformats only
> address a subset of the problem solved by RDFa.

The next step, then, is to list these problems, establish that they
truly aren't solved by existing solutions (not just Microformats),
establish that solving them would be of significant benefit to
authors, and finally that solving them within HTML is the most
appropriate course of action.

>>>>> So why RDFa and not Microformats?
>>>
>>> (I think the question should be why RDFa is needed *as well as* µformats)
>>
>> This is correct.  Microformats exist already.  They solve current
>> problems.  Are there further problems that Microformats don't address
>> which can be solved well by RDFa?  Are these problems significant
>> enough to authors to be worth addressing in the spec, or can we wait
>> and let the community work out its own solutions further before we
>> make a move?  We generally want to wait until a given item is truly
>> established before speccing it, so that we can work with existing
>
> Oh really? That's news to me.
>
> If this is principle we agree on that we really should start cutting lots of
> things from the spec.

It is a general principle, though not a necessary one.  As Ian noted
in his earlier email, speccing a solution too early runs the risk of
solving the wrong problem, and then poisoning that area of the
solution space entirely.  If we wait for authors to develop their own
hacks around features missing in the language, we can be sure that
we're solving a problem authors want solved, and we have some measure
of implementation experience already (even if just in author-deployed
Javascript) that we can learn from.  Other groups use this principle
as well - browser vendors prefix their early versions of new CSS
properties, for example, so that authors using these early versions
don't poison the space and prevent problems from being addressed that
would 'break' uses of the property.

Most the additions in HTML5 are designed on this principle.  For
example, the <video> element and the additional values for <input> are
drawn directly from javascript and flash-based solutions currently in
use, with the intent to make them easier for authors to use.  Others,
such as the additional sectioning elements and the new header-parsing
algorithm, were meant to embrace and bless well-established authoring
practices (splitting your content into header, footer, and content
<div>s, or building documents from smaller fragments which use <h1>
and such with clear intent to create a .  Finally, some additions (the
Workers spec, the SQL spec) have little in the way of current-practice
analogues (though much of those things are presaged in Gears, frex)
because they are designed to specifically address a current lack and
enable future uses.  These, though, still solve well-defined problems
and bring benefits which significantly outweigh their downsides.

RDFa isn't a well-established authoring pattern needing to be blessed
and made explicit.  That means it's either a simplification of
existing widespread hacks (Microformats?) intended to make authors
lives easier, or it's intended to fill a gaping hole that can be
established to be of significant benefit to authors to have filled.
Either way, one needs some justification.

Frex, it's possible that the language *could* be extended to make
Microformat-type things easier to use for authors.  We'd need to
establish that Microformats (or some other embedded metadata) really
are commonly used, though, and that the proposed simplification is
really significant enough (existing validation and video libraries,
for example, are much more complex to use than <input type="email"> or
<video>, and can impose significant extra bandwidth costs which are
undesirable).

It's also possible that embedded metadata support *is* a gaping hole
that needs to be filled.  We'd still need to (a) establish the problem
clearly (so we can evaluate possible solutions) and (b) decide that
RDFa is a good solution to the problem as stated before we add it into
the language.

~TJ