W3C home > Mailing lists > Public > whatwg@whatwg.org > May 2009

[whatwg] Annotating structured data that HTML has no semantics for

From: Eduard Pascual <herenvardo@gmail.com>
Date: Wed, 13 May 2009 20:16:54 +0200
Message-ID: <6ea53250905131116l3e8f9a4evdb7048de80507079@mail.gmail.com>
Let me start with some apologies:

On Tue, May 12, 2009 at 12:55 PM, Eduard Pascual <herenvardo at gmail.com> wrote:
> [...]
> Seeing that solutions are already being discussed
> here, I'm trying to put the ideas into a human-readable document that
> I plan to submit to this list either late today or early tomorrow for
> your review and consideration.
Oops, I'm already late with that. I had some unexpected compromises and
had no time to finish that doc. I still hope, however, to publish it today.

On Tue, May 12, 2009 at 12:55 PM, Eduard Pascual <herenvardo at gmail.com> wrote:
> [...]
> Third issue: also a flaw inherited from RDFa, it can be summarized as
> completelly ignoring the requirement I submitted to this list on April
> 28th, in reply to Ian asking us to review the use cases [1].
> [...]
> [1] http://lists.whatwg.org/htdig.cgi/whatwg-whatwg.org/2009-April/019487.html

On Tue, May 12, 2009 at 7:30 PM, Tab Atkins Jr. <jackalmage at gmail.com> wrote:
> Well, he didn't quite *ignore* it - he did explicitly call out that
> requirement to say that his solution didn't solve it at all.

I missed that part of Ian's post, sorry. I really read it from top to bottom,
but it was quite long. I guess I should have re-read it.
Now, after some re-reading, I have noticed a point I should reply to:

On Sun, May 10, 2009 at 12:32 PM, Ian Hickson <ian at hixie.ch> wrote:
> [...]
>     * Any additional markup or data used to allow the machine to understand
>       the actual information shouldn't be redundantly repeated (e.g. on each
>       cell of a table, when setting it on the column is possible).
>
> This isn't met at all with the current proposal. Unfortunately the only
> general solutions I could come up with that would allow this were
> selector-based, and in practice authors are still having trouble
> understanding how to use Selectors even with CSS.

First, I'd like to ask for a clarification from Ian: what do you mean by
"autrhos are still having trouble understanding how to use Selectors"?
If you mean that they have trouble when trying to select something like
"the second cell of the first row that has a 'foo' attribute different from
'bar' within tables that have four or more rows" or even more obscure stuff,
then I should agree: most authors will definitely have trouble dealing with
so complex cases, and I bet many will always have such trouble. However, if
you mean that authors can't deal with simple class, id, and/or
children/descendant
selectors, then I think you are seriously understimating authors.
On a side note, I'd like to advance that my idea, despite being Selector-based
(actually, I should say CSS-based: it reuses quite more than
selectors), wouldn't
require authors to use selectors at all, at least for the cases that
can currently
be solved by RDFa (or, FWIW, with the current Microdata approach on
the spec); the
same way a page can be completely styled with CSS without using
selectors, via the
"style" attribute.

On Tue, May 12, 2009 at 1:59 PM, Philip Taylor <excors+whatwg at gmail.com> wrote:
> On Tue, May 12, 2009 at 11:55 AM, Eduard Pascual <herenvardo at gmail.com> wrote:
>> [...]
>> (at least for now: many RDFa-aware agents vs. zero HTML5's
>> microdata -aware agents)
>
> HTML5 microdata parsers seem pretty trivial to write -
> http://philip.html5.org/demos/microdata/demo.html is only about two
> hundred lines to read all the data and to produce JSON and
> N3-serialised RDF. It shouldn't take more than a few hours to produce
> a similar library for other languages, including the time taken to
> read the spec, so the implementation cost for generic parser libraries
> doesn't seem like a significant problem.

Actually, I was thinking about the cost of deploying implementations,
rather than
writting them, since RDFa consumers are already out there and working. This,
however, strays a bit out of the original idea: it's not really a matter of how
big the cost is on its own, but of what do you get for that cost. This
is probably
my own fault, but I still fail to see what Ian's suggestion offers
that RDFa doesn't;
so my impression is that these costs, even if they are small, are
buying nothing, so
they are not worth it. If someone is willing to highlight what makes
this proposal
worth the costs (ie: what makes it better than RDFa), I'm willing to listen.

On Tue, May 12, 2009 at 2:30 PM, Shelley Powers
<shelleyp at burningbird.net> wrote:
> [...] Eduard, looking forward to seeing your own interpretation
> of the best metadata annotation.

Hey, who said my proposal will be, or try to be, the "best" one?
Definitelly, I didn't.
Actually, the reason to submit it here will be to have other people
look at it and
figure out ways to improve it (and I'm quite sure it can be improved,
I'm human after all).
Please, let me explicitly state that I don't pretend that idea to be
the "best" solution.
Since neither RDFa, nor Microformats, nor Ian's proposal could solve
my needs, my goal was
to build a solution that solves both my needs, and those solved by
other approaches, as a
proof that a solution that solves them all is *possible*.
Besides that, I'm glad I caught your interest.

On Tue, May 12, 2009 at 7:30 PM, Tab Atkins Jr. <jackalmage at gmail.com> wrote:
> [...]
> I floated a basic proposal for Cascading RDF[1] several months ago,
> and someone else (I think Eduard?  I'd have to check my archives) did
> something very similar.
>
> [1]: http://www.xanthir.com/rdfa-vs-crdf.php

First: yes, it was me. Second: I can't really say how similar my idea
was to your proposal
because, honestly, I'm still unable to understand it (maybe it could
take benefit of a bit of
explanation, since it's barely an intro and an example). Anyway, once
I publish mine and you
see it you should be able to figure out wether they are similar or
not. And hopefully, we
might take the best of each and put it together to make something that
is better than either
your proposal or mine ;)

> I don't see a good reason why that can't advance on a separate track,
> as (being out-of-band) it doesn't require changes to HTML to be usable.
Actually, my proposal would require a minor change to HTML (an
attribute, for which no specific
name is enforced, that would mirror CSS's "style" attribute).
In addition, this comment has raised a doubt: where should I post the
doc once it's ready?
In this thread? On a new thread on the list? Somewhere else?


This said, it's only left to go back to work and finish the proposal document.

Regards,
Eduard Pascual
Received on Wednesday, 13 May 2009 11:16:54 UTC

This archive was generated by hypermail 2.3.1 : Monday, 13 April 2015 23:08:49 UTC