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

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 00:27:01 UTC