New processing rules

Dear all,

I'm behind schedule with updates to the draft, mainly because I've
been implementing the new rules as a prelude to writing them up. I've
now got the code as compact as I think it will go, and it's turned out
to be much simpler than I thought it would. So I thought it worthwhile
to send the rules as I see them, to the list, so that people can look
at them and comment if they want. I'm thinking that this can go on in
parallel with me continuing with the syntax document, but might save a
little time.

Essentially the changes are to the processing of @rel/@rev, which
stores the incomplete triples when there is no object rather than
creating a bnode. There is also a new step that 'completes' the
incomplete triples.

However, during the course of working on this I've restructured the
part that establishes the subject, which I think ends up being easier
to follow.

Anything I don't mention, such as setting language or @base, is unchanged.


SETTING THE SUBJECT

The first step is to create a 'new subject' value, which is not yet
written into the context:

===
  If @about is present that always sets the subject;

  otherwise, if we have an inherited subject, that sets the subject;

  otherwise, if (
    @instanceof is present
    OR
    (there are 'incomplete triples' AND one of @rel, @rev or @property
is present)
  )
    set the subject to a bnode.
===

This seems to me a little easier than our old processing description.
It essentially amounts to @about always setting a new 'subject', no
matter what. (This is something that Ivan drew attention to when
looking at the new chaining approach.)

It also emphasises that if there is an object resource coming from the
parent statement, then it is always used as the subject, no matter
what the predicates are that appear on the statement currently being
processed.

The final step is only reached if there is no @about, and we have no
'inherited subject', which seems to me to be a useful clarification,
making it much easier to remember and read. In this situation we will
ALWAYS create a bnode if @instanceof is present, but we won't
necessarily create a bnode if one of @rel, @rev or @property is
present; in the latter situation we only create a bnode if there are
'incomplete triples'.

This combination provides a further useful clarification which is that
if there are no RDFa attributes present on an element then no bnode is
created.


COMPLETING TRIPLES

If a 'new subject' is established it is then used to complete any of
the incomplete triples that may have been stored. Once this has been
done the list is cleared, and the subject in the context is set to the
'new subject'.

There are three reasons I've done it this way; the first is that it
means we can get rid of the chaining flag, since we're now passing a
value down, when necessary. The second is that it allows us to
distinguish between a subject set by normal inheritance, and a subject
set via @resource, @href or @src, which is important for the proper
working of @instanceof. And finally, doing it this way means that when
we store 'incomplete triples' we only need to store the predicates,
rather than the subject as well. (We also need to store the
'direction', i.e., @rel or @rev.)

In the implementation of the code I've saved having to create an extra
flag in the context object, by simply doing a 'for' loop based on the
size of the array, which could of course be zero. If no-one
anticipates a problem, I'll also use the same technique in the
pseudo-code for describing the processing rules.


SETTING OBJECT RESOURCES

If there is an @href, @resource, or @src then processing is the same
as it is now, i.e., create the triples. However, instead of setting a
chaining flag on the context, we just pass the object down as an
inherited value, and this is then used to set the subject after a few
other things have happened (see above).

However, if none of these attributes are present, we no longer need to
create a bnode since that will be created in the subject-setting phase
(as described above) when processing is applied to any nested
statements. Instead, we store an 'incomplete triple' for each of the
predicates that is present. (Actually we need only store the
predicates.) The location of this array is the context object, which
means that it will be pushed and popped from the stack as processing
continues.


SETTING OBJECT LITERALS

As we have it now.


CHAINING FLAG

This is no longer needed.


NEXT STEPS

I'll endeavour to have these rules incorporated into the document for
tomorrow's meeting, but I'm getting a lot of things trying to steal my
time from me...so hopefully, even if I don't quite make it, this short
description should give everyone enough to go on, to see if everything
is starting to hang together.

Regards,

Mark

-- 
  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 Thursday, 13 December 2007 00:58:25 UTC