W3C home > Mailing lists > Public > public-rdf-in-xhtml-tf@w3.org > September 2007

Re: Issue on setting of [current resource] (addendum to Re: Issue on the latest syntax document: setting of [chaining])

From: Mark Birbeck <mark.birbeck@formsPlayer.com>
Date: Sun, 9 Sep 2007 15:21:49 +0100
Message-ID: <a707f8300709090721h7f8a5956rfbcc7c9fbaf4f543@mail.gmail.com>
To: "Ivan Herman" <ivan@w3.org>
Cc: public-rdf-in-xhtml-tf.w3.org <public-rdf-in-xhtml-tf@w3.org>

Ah...I think I see what's happening. :)

You are right that we need an extra flag, but I'd suggest we add one
called 'recurse'. You seem to have changed the meaning of my
'chaining' flag to fit recursion, and now you need to add another flag
for 'change resource'; but that is exactly what the 'chaining' flag
already does, so it seems just as easy to add a 'recurse' flag.

Are you ok with that Ivan? I'm basically saying that you are spot on
with the problem that you describing, but that the problem doesn't
actually really relate to chaining, but to recursion. We therefore
need a flag to inhibit recursion under the conditions you are
describing (when any nested mark-up serves as a literal).

Regards,

Mark

On 09/09/2007, Ivan Herman <ivan@w3.org> wrote:
> My apologies not to have realized that in my earlier mail.
>
> The current description relies on the value of [chaining] for setting
> the value of [current resource] to [current object resource]. That does
> not apply any more if what I say below is correct.
>
> Maybe not the most elegant, but the way I see solving this is to use yet
> another flag, called [change resource]. Using this flag, two changes:
>
> - The 3rd item in 3rd step currently says:
>
> "If any triples are generated then the [chaining] flag is set to true."
>
> which should be changed to
>
> "If any triples are generated then the [change resource] flag is set to
> true."
>
> - 4th step should say:
>
> 4. If the [change resource] flag is set to true then the [current
> resource] is set to the value of the [current object resource], and the
> [change resource] flag is set to false.
>
> I know I do not refer to @instanceof in this mail, but I will describe
> in my next mail why:-)
>
>
> Ivan
>
>
> Ivan Herman wrote:
> > To make the versioning clear, this is a comment on
> >
> > http://www.w3.org/MarkUp/2007/ED-rdfa-syntax-20070906/
> >
> > on Section 4.3, Processing
> >
> > At present, the flag [chaining] is bound to @rel, @rev, or @instanceof.
> > The processing steps say that _if_ any of those attributes generate
> > valid triples, (2nd and 3rd item in the 3rd step), then the [chaining]
> > flag is set to True. Otherwise it is False (although this latter is not
> > explicitly said in the text). I am not sure that is correct. Inspired by
> > Mark's beloved example:-):
> >
> > <span property="a:bla" rel="p:q" resource="http://a.b.c">Einstein said
> > E=mc<sup>2</sup></span>
> >
> > This will generate the triples
> >
> > <> p:q <http://a.b.c>;
> >    a:bla "Einstein said E=mc<sup>2</sup>"^^rdfs:XMLLiteral.
> >
> > which is fine, but I do not think that chaining should go beyond the
> > <span> element in this case. Put it in an informal way, [current object
> > literal] has already provided for a correct interpretation of that
> > content...
> >
> > I think the correct way of saying this is that:
> >
> > - [chaining] is set to True by default when entering processing [current
> > element]
> > - [chaining] is set to False, if
> >    - no @content attribute is present
> >    - any triples are generated using the [current object literal], ie,
> >      first item in 3rd step.
> >
> > Ivan
> >
>
> --
>
> Ivan Herman, W3C Semantic Web Activity Lead
> Home: http://www.w3.org/People/Ivan/
> PGP Key: http://www.ivan-herman.net/pgpkey.html
> FOAF: http://www.ivan-herman.net/foaf.rdf
>
>


-- 
  Mark Birbeck, formsPlayer

  mark.birbeck@formsPlayer.com | +44 (0) 20 7689 9232
  http://www.formsPlayer.com | http://internet-apps.blogspot.com

  standards. innovation.
Received on Sunday, 9 September 2007 14:21:54 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 17:01:52 UTC