- From: Gregg Kellogg <gregg@kellogg-assoc.com>
- Date: Sun, 25 Sep 2011 16:21:55 -0400
- To: Ivan Herman <ivan@w3.org>
- CC: Toby Inkster <tai@g5n.co.uk>, W3C RDFWA WG <public-rdfa-wg@w3.org>
On Sep 21, 2011, at 5:46 PM, Ivan Herman wrote: > > On Sep 21, 2011, at 08:07 , Toby Inkster wrote: > >> On Wed, 21 Sep 2011 06:28:00 -0700 >> Ivan Herman <ivan@w3.org> wrote: >> >>> my implementation is slightly different, but Gregg's is following the >>> algorithm by the letter. Gregg? >> >> OK, got it working. >> >> My mistake it seems is that while the prefix mapping needs to be passed >> from a parent to child evaluation context by value (to avoid a prefix >> declaration on the child element affecting its ancestors), the list >> mapping needs to be passed by reference. >> > > I wonder whether there is some remark to be done in the document to make that clearer? > > (Sorry, I am on a meeting now, hence I cannot really look into the text proper...) The relevant bits seem to be from the following steps: [[[ 1. the list mapping is set to the list mapping from the evaluation context; 8. The list mapping taken from the evaluation context is set to a new, empty mapping. 12. the list mapping is set to the local list mapping; ]]] Similar language for IRI and Term mappings also says to copy the mapping, but the implication is that it is a copy-by-value, as any changes should not be reflected in ancestor element evaluation contexts. In the case of list mappings, a reference to the mapping is taken, so that the same mapping exists for everything sharing a common subject within an evaluation-context stack. When a new subject is detected, it is replaced by a new empty mapping (step 8), which get's copied into a new evaluation context (step 12). Perhaps it would be clearer if we replaced those phrases with the following: [[[ 1. the list mapping is set to /a reference of/ the list mapping from the evaluation context; ]]] I don't think the wording in steps 8 or 12 need to be changed. >> I have one further comment: in stage 14, it does not state how to >> handle when a list exists but is empty. Initially I thought that >> perhaps the previous processing steps ensure that this state is never >> reached. But I was incorrect - sometimes, there will be an empty list. >> >> For example, processing the following: >> >> <html> >> <head><title>Test</title></head> >> <body><br rel="rdfa:testing" inlist="" /></body> >> </html> >> >> In this case I'm generating: >> >> <> rdfa:testing () . > > I think that is right per spec. > >> >> Though another option would be to simply generate no triple from it. > > Indeed but, after all, the author _did_ use the onlist attribute, so an empty list seems to be appropriate for me... > > Thanks! > > Ivan > > >> >> -- >> Toby A Inkster >> <mailto:mail@tobyinkster.co.uk> >> <http://tobyinkster.co.uk> >> >> > > > ---- > 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 Sunday, 25 September 2011 20:23:12 UTC