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

Re: Different treatment of @resource between RDFa 1.0 and 1.1

From: Ivan Herman <ivan@w3.org>
Date: Sat, 19 May 2012 17:03:23 +0200
Cc: Oskar Welzl <lists@welzl.info>, "Jeffrey, Alan S A (Alan)" <alan.jeffrey@alcatel-lucent.com>, "public-rdfa@w3.org" <public-rdfa@w3.org>
Message-Id: <86797BA0-39D7-461D-AF0F-4F5C52FB0773@w3.org>
To: Alan Jeffrey <ajeffrey@bell-labs.com>

the reason is simple: I had a bug:-)

Actually, the interesting is not the HTML5 mode. I presume what Oskar did was to say something like:

<foo xmlns:ex="http://example.com/ns#" resource="http://example.com/foo">
    <link rel="ex:bar" href="http://example.com/baz"/>

Or, if he did not do it by hand, the HTML5 parser does it when generating the DOM!

Whereas the xml mode, ie, what you tried, was something like:

<?xml version="1.0" encoding="UTF-8"?>
<foo xmlns:ex="http://example.com/ns#" resource="http://example.com/foo">
    <link rel="ex:bar" href="http://example.com/baz"/>

ie, the element was the top element of the XML file, ie, the generated DOM. Well... that is where I had a bug: I indeed insert an artificial @about to the top of the tree (unless there is an @about there) to set the default subject to the base URI, but I should not do this in the situation you have there. This type of error practically never occurred in HTML, because authors rarely touch the HTML element but, well, Murphy's law...

I have updated the file. I do not know whether you use the code pulled from github or whether you use the distiller directly, but it should work now.



On Apr 23, 2012, at 16:40 , Alan Jeffrey wrote:

> On 04/22/2012 03:46 PM, Oskar Welzl wrote:
>>> but the 1.1 distiller generates different output (the @about value
>>> has changed):
>> two distillers, three tries, two results:
> Ah, that's interesting, I hadn't tried it in HTML5 mode. How odd.
>>> Digging through the 1.1 spec (Sec 7.5, processing rule 5) it looks like
>>> the distiller is doing the right thing: the @resource attribute only
>>> sets the current object resource when there's an @rel, @rev or @property
>>> attribute.
>> This is just for my own understanding, my last post here shows I have
>> problems understanding this myself, but: The way I read it, the
>> @resource in your example *does* set a new subject:
> Yes, it sets a "new subject" (7.5, 5, alt 2) but not a "current object resource". In the case where there is a @property (7.5, 5, alt 1) or @rel (7.5, 6) the "current object resource" gets set to the @resource.
>> According to 7.5, 6.:
>> <link rel="ex:bar" href="http://example.com/baz"/>
>> contains @rel (that's why we're in 6.) but nothing that would match a
>> "set new subject"-rule; so we keep "http://example.com/foo" from the
>> parent as the subject. The object resource is taken from @href according
>> to this processing rule.
>> (Grant's table: [Current object resource] in "rel | rev mode")
> Ah, you may be right, I didn't read (7.5, 13) correctly. When recursively processing nodes "the parent object is set to value of current object resource, if non-null, or the value of new subject, if non-null, or ..." In this case, the "current object resource" is null, so the parent object should be set to the "new subject", which in this case is <http://example.com/foo>, not <>.
> So perhaps this is a bug with the distiller rather than a change in the spec? (This would make me happy, as it would mean no change to our RDFa!)
>> Cheers,
>> Oskar
> A.

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 Saturday, 19 May 2012 15:00:06 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 17:04:49 UTC