- From: Mark Birbeck <mark.birbeck@webbackplane.com>
- Date: Thu, 21 Oct 2010 09:14:12 +0100
- 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