W3C home > Mailing lists > Public > public-rdfa-wg@w3.org > October 2010

Re: Tightening up the spec on what exactly an RDFa profile is

From: Mark Birbeck <mark.birbeck@webbackplane.com>
Date: Thu, 21 Oct 2010 09:14:12 +0100
Message-ID: <AANLkTinxCwagH3nte-ZHVA-ZZbV=QauDXW+y_qVDt_UH@mail.gmail.com>
To: Shane McCarron <shane@aptest.com>
Cc: RDFa WG <public-rdfa-wg@w3.org>
Thanks Shane.

On Thu, Oct 21, 2010 at 1:26 AM, Shane McCarron <shane@aptest.com> wrote:
> I consider these editorial changes.  I have comments inline:
>
> On 10/20/2010 4:41 PM, Mark Birbeck wrote:
>>
>> Hello all,
>>
>> I'm just finalising some comments on profile formats, but during the
>> course of the work it has seemed to me that we bend the stick a little
>> too far in our definition of a profile as an external document.
>>
>> This isn't actually how it was first conceived; the initial
>> discussions on 'profile' saw it as an extension of the HTML notion of
>> profile. In HTML we have a URI that identifies a collection of terms,
>> but no definition of how they might be loaded if a processor doesn't
>> recognise the URI. Our extension to that is to *add* a definition of
>> how profiles might be retrieved, but we don't want to lose the
>> foundation.
>>
>> I realise that there are a couple of notes that make the point about
>> 'embedding' profile information:
>>
>>   Embedding definitions for well known, stable RDFa Profiles in the
>>   implementation is recommended.
>>
>> but I don't think they bring the issue to the fore.
>>
>> So my first suggested change would be to 'Status of this Document':
>>
>>  4. The ability to reference external RDFa Profile documents; these are
>>      used to ease authoring by creating vocabulary term collections.
>>
>> =>
>>
>>  4. The ability to reference RDFa Profiles; these are used to ease
>>      authoring by creating vocabulary term collections.
>
> Done.   Actually this should have mentioned not just terms, but also
> prefixes and default vocabulary.  I fixed that at the same time.
>
>>
>> Also, in section 5 'Attributes and Syntax' I'd change:
>>
>>   prefix
>>     a white space separated list of one or more URIs that reference
>>     external definitions of terms and/or prefix mappings. See [RDFa
>>     Profiles];
>>
>> =>
>>
>>   prefix
>>     a white space separated list of one or more URIs that indicate
>>     a profile of terms and/or prefix mappings. See [RDFa Profiles];
>
> Done.  But I think you meant 'profile', not 'prefix'.
>>
>> In section 7.2 'Evaluation Context' I'd remove the word 'document'
>> from the very end of this paragraph:
>>
>>   The default vocabulary, a value to use as the prefix URI when a term
>>   is used. This specification does not define an initial setting for the
>>   default vocabulary. Host Languages may define an initial setting. If a
>>   Host Language defines an initial setting, it should do so via an RDFa
>>   Profile document.
>
> Done.
>
>>
>> Note that at the top of section 7.5 we already talk of an 'RDFa
>> Profile' rather than an 'RDFa Profile document', which is fine. But at
>> step 2 I'd change:
>>
>>   If any referenced RDFa Profile is not available...
>>
>> =>
>>
>>   If any referenced RDFa Profile is not recognised...
>>
>> And then explain 'recognised' in the 'RDFa Profile' section.
>
> Done and done.
>
>>
>> In section 7.6 'Processor Status' I'd change the second bullet:
>>
>>   An ERROR must be generated when an RDFa Profile document fails to
>>   be retrieved and thus, a portion of the document fails to be processed.
>>
>> =>
>>
>>   An ERROR must be generated when a referenced RDFa Profile is not
>>   recognised, as described in [RDFa Profiles].
>
> Done.
>
>> In section 9 'RDFa Profiles' I'd change:
>>
>>   RDFa Profiles are optional external documents that define collections of
>>   terms and/or prefix mappings.
>>
>> =>
>>
>>   RDFa Profiles are collections of terms and/or prefix mappings. A profile
>>   is either intrinsically known to the parser, or it is loaded as an
>> external
>>   document and processed.
>
> Done.
>
>>
>> Before step 1, I would add a new step 1:
>>
>>   If the URI is known to the parser then:
>>     * all prefix mappings are loaded into the [local list of URI
>> mappings];
>>     * all term mappings are loaded into the [local term mappings];
>>     * any default vocabulary setting is used to update the
>>       [default vocabulary].
>>
>>
>> At step 2 (the old step 1), I would change:
>>
>>   Attempt to retrieve the content of the URI. If the retrieval fails, stop
>>   processing any additional URIs and do not perform any any potential
>>   mapping updates.
>>
>> =>
>>
>>   If the URI is not known to the parser, then attempt to retrieve the
>>   content of the URI. If the retrieval fails, stop processing any
>> additional
>>   URIs, generate an error (see [Processor Status]) and do not perform
>>   any potential mapping updates.
>
> Done.  Thanks for being so detailed - it made the updates / clarifications
> easy.
>
>>
>> Regards,
>>
>> Mark
>>
>> --
>> Mark Birbeck, webBackplane
>>
>> mark.birbeck@webBackplane.com
>>
>> http://webBackplane.com/mark-birbeck
>>
>> webBackplane is a trading name of Backplane Ltd. (company number
>> 05972288, registered office: 2nd Floor, 69/85 Tabernacle Street,
>> London, EC2A 4RR)
>>
>
> --
> Shane P. McCarron                          Phone: +1 763 786-8160 x120
> Managing Director                            Fax: +1 763 786-8180
> ApTest Minnesota                            Inet: shane@aptest.com
>
>
>
Received on Thursday, 21 October 2010 08:15:30 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 17:05:21 UTC