Re: order within a @prefix

Hi Ivan,

I guess in one sense left-right v. right-left doesn't make much
difference. However, our processing rules generally have a sort of
'later overrides earlier' aspect to them, based on the hierarchical
nature of the documents that we're parsing. Having a rule where the
deeper nodes override their parents' values makes processing very
easy.

Now, of course you could say that 'latest wins' would still be the
rule inside the @prefix attribute if we processed from right to left.
But I do think that would be a little odd, given that conventionally
people see the DOM hierarchy as going from left to right.

To illustrate, our processing model would say that the second
occurrence of 'foaf' in this example applies due to the hierarchy (in
a sense, it's 'later overrides earlier'):

  <div prefix="foaf: http://blah1">
    <div prefix="foaf: http://blah2">
      <!-- use blah2 --->
    </div>
  </div>

Writing an example where the same prefix is defined in @prefix might
look like this:

  <div prefix="foaf: http://blah1
                    foaf: http://blah2">
      <!-- should really use blah2 --->
    </div>
  </div>

I think it would be counterintuitive if the left-most prefix was
preferred over the right-most one, in this example.

This simplicity of overriding is lost in the processing of profiles
(as a result of the resolution you refer to on ISSUE-23). The way that
the processing is now described in section 9 implies that you need to
track each profile loaded to see if there is a conflict later. Of
course, the easiest way to implement this is to process from right to
left, which removes the need to track each profile, but then I think
most implementers will rightly ask...why is everything else going from
left to right, except @profile?

We know that the only reason profile processing was made to work from
right to left was due to the legacy use of @profile, in which only the
first value had significance; some argued that this implied that the
left-most profile should be the most important, and therefore should
override others.

Personally, I didn't find this very convincing (and the resolution
didn't have great support), but we have the resolution now.

However, given that we have the resolution to deal with a legacy
issue, it should really be regarded as an anomaly, I it certainly
shouldn't be used as a model for other processing rules.

Regards,

Mark


On Thu, Dec 2, 2010 at 9:56 AM, Ivan Herman <ivan@w3.org> wrote:
> Shane,
>
> there is no separate comment list; the reference in the document for comments is the WG mailing list...
>
> But yes, this _is_ a last call comment, though I thought it is an editorial issue.
>
> So, to make it clear, the question is what is the effect of @prefix="a: http://a.b a: http://c.d". In my original mail I said it should be left to right. But I since seemed to remember that we decided to have it right to left, ie, in my example, the result should be a->http://a.b. I tried to find a resolution in the mail archives, but I could not. However I did find this:
>
> http://lists.w3.org/Archives/Public/public-rdfa-wg/2010May/0123.html
>
> which led to a discussion thread on the relative priority within a @profile. This led to this resolution:
>
> http://www.w3.org/2010/02/rdfa/meetings/2010-06-03#resolution_7
>
> ie, left-most declaration wins. I have not found any resolutions related to @prefix. However, based on the the resolution we have already taken for @profile I would propose to define the same order for @prefix and that should be documented in RDFa 1.1 Core
>
> Ivan
>
>
>
>
> On Dec 2, 2010, at 02:01 , Shane McCarron wrote:
>
>> Since we are in last call, please submit this as a last call comment to the appropriate public list before the deadline.
>>
>> On 12/1/2010 6:16 PM, Toby Inkster wrote:
>>> On Wed, 1 Dec 2010 11:21:55 +0100
>>> Ivan Herman<ivan@w3.org>  wrote:
>>>
>>>> @prefix="a: http://a.b a: http://c.d"
>>>>
>>>> will end in a->http://c.d
>>>>
>>>> However, I tried to locate this in the document and I could not...
>>> That's what I do, but I agree we need to make this explicit as it's a
>>> case that implementors will definitely need to handle.
>>>
>>
>> --
>> Shane P. McCarron                          Phone: +1 763 786-8160 x120
>> Managing Director                            Fax: +1 763 786-8180
>> ApTest Minnesota                            Inet: shane@aptest.com
>>
>>
>
>
> ----
> Ivan Herman, W3C Semantic Web Activity Lead
> Home: http://www.w3.org/People/Ivan/
> mobile: +31-641044153
> PGP Key: http://www.ivan-herman.net/pgpkey.html
> FOAF: http://www.ivan-herman.net/foaf.rdf
>
>
>
>
>
>

Received on Thursday, 2 December 2010 12:15:27 UTC