W3C home > Mailing lists > Public > www-archive@w3.org > August 2008

RE: [whatwg] Creative Commons Rights Expression Language

From: Bonner, Matt <matt.bonner@hp.com>
Date: Fri, 22 Aug 2008 18:40:20 +0000
To: Ben Adida <ben@adida.net>, Ian Hickson <ian@hixie.ch>
CC: Dan Brickley <danbri@danbri.org>, Kristof Zelechovski <giecrilj@stegny.2a.pl>, Tab Atkins Jr. <jackalmage@gmail.com>, Henri Sivonen <hsivonen@iki.fi>, "www-archive@w3.org" <www-archive@w3.org>
Message-ID: <57221E38FB4DD54C946CE654959A554D1AAB9039E3@GVW0436EXB.americas.hpqcorp.net>
Ben Adida wrote:

> Not that you have to take the time, of course, I'm sure you're busy.
> But if you're going to spend time arguing with us, then please argue
> with us about what we actually need, not about what you think we need.

Is that the only point of discussion?  Seems like understanding the
history, decisions and constraints of the HTML5 standard should be 
considered as well.

Ian Hickson wrote: 
>> You can create your own vocabularies without clashing with the
>> Microformats community and without introducing extensions to HTML.
> How do you know you're not clashing? Especially if others are doing
> the same thing, without talking to the uF community? Whatever
> happened to the web extensibility model, where you mint a URI at a
> domain you own?

Well, if you used <link> instead of <a>, there's the RelExtensions wiki..


What motivated the use of <a>, anyway?  It would be useful to add some
background to the next draft of the Submission that explains the
rationale for the design choices. Please point me to it if I missed
where ccREL explains it.

> Again, please read the ccREL paper, and my last email, which explains
> that we need to mark up quite a bit more than a license link.

Well, section 3.1 of the Submission says:

  "A publisher who wishes to license a Work under a Creative
  Commons license must, at a minimum, provide one RDF triple that
  specifies the value of the Work's license property"

> You seem
> to think our problem is simpler than a single vocab like Atom, when
> actually it is far more complex, because we need to annotate many
> different data types, so we need the vocabulary modularity that
> Microformats simply don't have.

Perhaps it would be better to start over and engage the HTML5 
community on your requirements, what makes sense and proceed from there?
Coming with a complete Submission and accepting no compromises doesn't
seem like the route to productive discussion.

>> Adding to the language is not friendly to that language, especially
>> when that language has as many existing extension mechanisms as HTML.
> So far, we've added to XHTML because it's extensible. There's
> community interest (expressed by others at the start of this thread)
> in seeing if HTML5 might adopt RDFa attributes. What is the
> difference between that proposal and your proposals to extend HTML?
> What makes your proposals "friendlier?"

Well, for example, HTML5 provides the data-* attributes. Could ccREL
use those instead?  To flip what you have said, perhaps reading/skimming
the "extensions" sections HTML5 spec would help the ccREL advocates 
understand how best to fit ccREL into HTML5.

Matt Bonner
Hewlett-Packard Company

Received on Friday, 22 August 2008 18:43:26 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 22:33:31 UTC