Let's say we've just added the triple below to the datasource.

subject: http://www.xulplanet.com/ndeakin/images/t/obelisk.jpg
predicate: http://purl.org/dc/elements/1.1/description
object: One of the thirty or so Egyptian obelisks

The template builder will be notified through the RDF observer mechanism of the change. The template builder will need to check all of the rules to see if this triple could cause a change in what would be displayed. If the triple wouldn't cause any change in the output, the builder won't make any changes. If the output would change, the builder will need to adjust the output, either by adding a new result, removing an old result, or by changing the value of some part of the result. The builder is smart enough to only change what needs to be changed and leave the remaining parts alone. Let's assume we have single rule with conditions as follows:

  <content uri="?start"/>
  <member container="?start" child="?photo"/>
  <triple subject="?photo"
  <triple subject="?photo"

These conditions will cause any photos with both a title and a description to be displayed. Assuming that the 'obelisk' photo doesn't have a description already, adding the triple listed above should cause a new result to be available for this photo. The builder scans through the conditions one by one.

The <content> tag can safely be skipped at this part of the process, so the builder moves onto the <member> condition. This type of condition can only cause a change when an item is being added or removed from a container. Since this is a new RDF triple that isn't an addition or removal from a container, this condition can be skipped. Effectively, if the result generation process was to evaluate this member condition, the same output would be supplied for the ?photo variable whether the new data is there or not. Thus, the member condition can be skipped.

The next condition is a <triple> involving the "http://purl.org/dc/elements/1.1/title" predicate. We aren't adding a arc involving this triple so we can ignore this conditon as well. The second triple, however, could cause a change, since the predicate attribute matches the predicate being added. The subject and object are variables so the builder accepts this as a possible change, and moves on to the next step. If the predicate was different, the builder would come to the end of the conditions and could just stop there. For instance, if the predicate of the triple being added was "http://purl.org/dc/elements/1.1/date", the builder could ignore it since the template doesn't even care about the date field. Similarly, if the triple didn't use a variable but a static value, this value would also need to match in order to continue processing.

Now that we know the conditions could cause a change in the template, the second step is to fill in the variables for this condition for what could potentially be a new result. In this situation, it fills in the ?photo and ?description variables using the values from the newly added triple.

(?photo = http://www.xulplanet.com/ndeakin/images/t/obelisk.jpg,
 ?description = 'One of the thirty or so Egyptian obelisks')

Next, the builder works its way backwards through the rules, in order to fill in the remaining variables. It does this in a similar manner as it does when it generates results, but traverses the rules in the opposite order. The previous triple will fill in a value for the ?title variable, since we now have a value for the ?photo variable referred to by the triple's subject attribute. Next, the <member> condition is examined, and, in this situation, the builder fills in the known ?photo variable, and looks for a parent container containing this value. There is a container "http://www.xulplanet.com/rdf/myphotos", so the ?start variable will be filled in with this value. Now, the potential result so far is:

(?photo = http://www.xulplanet.com/ndeakin/images/t/obelisk.jpg,
 ?description = 'One of the thirty or so Egyptian obelisks',
 ?start = http://www.xulplanet.com/rdf/myphotos,
 ?title = 'Obelisk')

As you can see, the result looks to have all the information necessary to create a new item in the output. If a condition hadn't generated a result, for instance if the photo did not have a title, or it wasn't contained in a parent container, there would be no match and the builder could stop processing the new triple. For instance, we might have added a description for a new photo, but haven't added the photo to the container resource. Once we do add it to the container with another RDF assertion, the process described above is applied again and this time it may match.

There are still two more things to do before a result is accepted as a new match. First, once the builder reaches the <content> condition, it checks what the container or reference variable is, in this case ?start, as specified by the uri attribute. The calculated value for the potential new match is "http://www.xulplanet.com/rdf/myphotos". The builder looks to see if this resource is being used as the stating point in the template. As it happens, this resource is being used, since it is the value of the ref attribute we've been using in these examples. This would also be the case for any starting points used in recursive generation. If the calculated ?start variable was something different, naturally we don't need to change the template output, as that resource isn't being used in a template.

Finally, the builder processes any conditions below the one we started at, in order to fill in any remaining variables. In this case, there are no other conditions, so the builder accepts this result as a new match. Since all the variables have been filled in, the action body for the rule can be processed and a new block of content generated and inserted into the output. We'll find out how the builder determines where to insert the new content is an upcoming section. However, this does show that the template builder can update the output upon changes without rebuilding the entire template.

When an unassertion occurs, or data is removed from the datasource, a different process is used. In this case, the builder looks at the results and determines which ones to remove. When it had first generated the results, the builder stored extra information to specify what parts of the graph were navigated over. It uses this information to help determine what results are no longer needed.

We'll look a bit more at how RDF changes affect the template next.