W3C home > Mailing lists > Public > public-rdfa-wg@w3.org > December 2012

Re: New Editor's Draft for HTML+RDFa 1.1

From: Gregg Kellogg <gregg@greggkellogg.net>
Date: Mon, 10 Dec 2012 14:21:06 -0500
To: Niklas Lindström <lindstream@gmail.com>
CC: Ivan Herman <ivan@w3.org>, Manu Sporny <msporny@digitalbazaar.com>, RDFa WG <public-rdfa-wg@w3.org>
Message-ID: <1219A659-1A67-48CD-A6B7-56135F144DD4@greggkellogg.net>
On Dec 10, 2012, at 11:01 AM, Niklas Lindström <lindstream@gmail.com> wrote:

> On Mon, Dec 10, 2012 at 12:51 PM, Ivan Herman <ivan@w3.org> wrote:
>> 
>> On Dec 9, 2012, at 11:47 , Niklas Lindström wrote:
>> 
>>> On Sun, Dec 9, 2012 at 1:06 PM, Ivan Herman <ivan@w3.org> wrote:
>>>> 
>>>> On 9 Dec 2012, at 04:35, Niklas Lindström <lindstream@gmail.com> wrote:
>>>> 
>>>>> Hi,
>>>>> 
>>>>> I found a problem in the latest draft. In  "3.1 Additional RDFa
>>>>> Processing Rules", it says to use "HTMLLiteral" from the RDF
>>>>> vocabulary. But according to "RDF 1.1 Concepts and Abstract Syntax:
>>>>> 5.2 The rdf:HTML Datatype" [1], that should be just "HTML". So replace
>>>>> the two occurrences of "HTMLLiteral" with "HTML".
>>>> 
>>>> Good catch!
>>> 
>>> Thanks. ;)
>>> 
>>>>> 
>>>>> Also, I think it's great that @value is supported. IIUC, it means that
>>>>> @value from <input> elements also can be captured with RDFa, correct?
>>>>> But I wonder why @value is defined to override @content, and not vice
>>>>> versa? I don't recall the reasons for that. (I was expecting @content
>>>>> to work just like @resource overrides @href. I.e. to always override
>>>>> any host language specific attribute; in this case, @value.)
>>>> 
>>>> To be honest, I do not remember. I am on my mobile now, cannot check; the same question arises for time, doesn't it?
>>> 
>>> You mean @datetime? Basically yes. Perhaps it was argued that
>>> @datetime is more specific than @content? Regardless, I'm not sure the
>>> same can be said for @value. I think it would be more predicable if
>>> @content is considered "strongest". (Unless this leads to more
>>> complicated rules, but it doesn't seem so.)
>> 
>> To be honest, I do not remember having discussed this in the past. I must admit I do not have strong feeling about this, although the @href/@resource example is compelling indeed.
>> 
>> I agree this is a decision we have to do soon, hopefully before the next publication round (although... with the publication moratorium kicking in this week, maybe it is better not to rush and leave this as an open issue for last call).
> 
> I'm fine either way. I'd perfectly open to having a telecon on
> thursday this week to discuss this, prototypes and @resource-in-link
> if people see fit. Would that be viable?
> 
>> FWIW my implementation does not take @content into account right now; it actually overrides one if it is there. But it is easy to change it.
>> 
>>> 
>>> Also, I think there is another issue in "4. Extensions to the HTML5
>>> Syntax". We do say "If the RDFa property attribute is present on the
>>> link element, the rel attribute is not required.", which is good. But
>>> I believe we must also add:
>>> 
>>>   If the RDFa resource attribute is present on the link element, the
>>> href attribute is not required.
>>> 
>>> Otherwise, if you want to use bnode references (or an empty value to
>>> resolve to base, which apparently isn't allowed in link/@href [1]),
>>> you must also add an unused non-empty @href just to be compliant.
>> 
>> Sorry, it is early morning for me... I do not understand this.
> 
> What I mean is that, in HTML5, using e.g.:
> 
>    <link rel="rdfa:ref" resource="_:proto">
> 
> isn't valid. Link elements have to have an @href. And that @href must
> not be empty [1], nor does it support CURIEorIRI. It would be very
> cumbersome to have to write the above like:
> 
>    <link rel="rdfa:ref" resource="_:proto" href="#ignored">
> 
> (In fact, at the moment, the HTML5 validator [2] complains about that
> too, saying: "Attribute resource not allowed on element link at this
> point.")
> 
> Hence, I believe we should add: "If the RDFa resource attribute is
> present on the link element, the href attribute is not required." Or
> not recommend link for this and favor e.g. empty <a> or <span>
> elements.

+1. I'm certainly guilty of using this pattern, if if we can't use @resource with <link>, then there's not a good way to do a hidden reference to a BNode identified resource.

Gregg

> Best regards,
> Niklas
> 
> [1]: http://www.w3.org/TR/2011/WD-html5-20110113/semantics.html#the-link-element
> [2]: http://html5.validator.nu/
> 
> 
>> Ivan
>> 
>> 
>> 
>>> 
>>> Best regards,
>>> Niklas
>>> 
>>> [1]: http://developers.whatwg.org/semantics.html#attr-link-href
>>> 
>>> 
>>> 
>>>> Ivan
>>>> 
>>>> 
>>>> 
>>>>> 
>>>>> Best regards,
>>>>> Niklas
>>>>> 
>>>>> [1]: http://www.w3.org/TR/rdf11-concepts/#section-html
>>>>> 
>>>>> On Sun, Dec 2, 2012 at 8:39 PM, Manu Sporny <msporny@digitalbazaar.com> wrote:
>>>>>> A new editor's draft for HTML+RDFa 1.1 has been published which
>>>>>> incorporates all decisions made by the newly re-chartered RDFa WG to
>>>>>> date. As of this moment, there are no plans to add any new features or
>>>>>> remove existing features from HTML+RDFa 1.1. This document is probably
>>>>>> the one that is going to go to Last Call, so please review it and try to
>>>>>> find any issues or problems:
>>>>>> 
>>>>>> http://www.w3.org/2010/02/rdfa/drafts/2012/ED-rdfa-in-html-20121202/
>>>>>> 
>>>>>> You can view a diff of the changes here:
>>>>>> 
>>>>>> http://www.w3.org/2010/02/rdfa/drafts/2012/ED-rdfa-in-html-20121202/diff-20120911.html
>>>>>> 
>>>>>> -- manu
>>>>>> 
>>>>>> --
>>>>>> Manu Sporny (skype: msporny, twitter: manusporny)
>>>>>> Founder/CEO - Digital Bazaar, Inc.
>>>>>> blog: The Problem with RDF and Nuclear Power
>>>>>> http://manu.sporny.org/2012/nuclear-rdf/
>>>>> 
>> 
>> 
>> ----
>> Ivan Herman, W3C Semantic Web Activity Lead
>> Home: http://www.w3.org/People/Ivan/
>> mobile: +31-641044153
>> FOAF: http://www.ivan-herman.net/foaf.rdf
>> 
>> 
>> 
>> 
>> 
> 
Received on Monday, 10 December 2012 19:21:51 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 21:19:57 UTC