Tightening up the spec on what exactly an RDFa profile is

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.


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];


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.


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.


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].

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.


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.


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)

Received on Wednesday, 20 October 2010 21:42:40 UTC