Procedimiento

The insertion, deletion, and replacement specifications introduced in the previous sections augment query terms for obtaining update term specifications. The premise of modifying desired data terms is that the query terms – called subjacent query terms – simulation unify with the data terms. This is the case for up- dating data terms that contain data (i.e. they are not empty) or the data need not be overwrite. Forupdating the root– inserting a data term into an empty Web resource (actually ’constructing’ a new resource), delet- ing the whole data term found at a Web resource (actually deleting the resource), or overwriting (replacing) the data term at a Web resource – a subjacent query term is neither needed nor allowed, a single update operation will do.

Imagine an XChange update like a function that takes as arguments an update term and a data term, and returns a (updated) data term. Data terms represent trees (cf. Section 2.2.1), thus, an XChange update can be represented as a function that applies an update term to a tree for obtaining the updated tree. Regardless whether one wants to update the root of a tree, the whole tree, or just parts of it, the result of the update needs to be atree. This requirement has consequences on the possible update operations for updating the root. Their syntax is the same as for the update operations introduced so far; though, not all update specifications are allowed for updating the root so as not to violate the previously given requirement.

The following grammar rules define the possible update operations for updating the root:

4.6. UPDATE PATTERNS

U_Root ::= "insert" Construct_Term | "delete" Query_Term

| Query_Term "replaceby" Construct_Term

Insertion as Root In XChange, the update used for inserting data (more precisely a data term) at a given Web resourceReshas the following form

in { resource { Res },

insert Construct_Term }

The resource specification is given to emphasise the absence of a query term acting as a subjacent one. Notethat if the given Web resource contains data (it is not empty), the above given update term constructs a new data term that overwrites the data found atRes. Update operations of one of the following forms

insert all Construct_Term

insert some Nr Construct_Term , with 0 < Nr

insert first Nr Construct_Term , with 0 < Nr

are not allowed for updating the root. They result in not having a tree representation of data, but aforest (a sequence of trees). If one wants to insert e.g. all instances of a construct term in an empty resource, an artificial root should be provided.

Example 4.49 (Insertion as Root)

After the next update is executed, the data term found athttp://software.de/products.xml is found athttp://sn.de.

in { resource {"http://software.de/products.xml"},

insert var C }

The condition part of the XChange rule having the above given update term as action part contains the following Xcerpt query that binds the variableC:

in { resource {"http://sn.de"}, var C → Catalogue {{ }} }

Deletion of the Root For deleting whole data of a given Web resource (i.e. the resource), a query term matching it needs to be specified. The XChange update for deleting the (data of) Web resourceReshas the form

in { resource { Res }, delete Query_Term }

Clearly, ifQuery Termhas the formdesc query patternthe data term atResremains unchanged. Note that an update term of the formdelete var Rootresults in deleting the data term regardless of its structure. Update terms of one of the following forms

delete some Nr Query_Term , with 0 < Nr delete first Nr Query_Term , with 0 < Nr

are not allowed. They do not have an intuitive meaning when updating the root; thus, are not considered as update terms in XChange.

Example 4.50 (Deletion of the Root)

An update that specifies the deletion of the data ofhttp://software.de/products.xml (i.e., the entire XML document is to be deleted).

in { resource {"http://sn.de"},

delete Catalogue {{ }} }

CHAPTER 4. PARADIGMS. CONCEPTS. SYNTAX Replacement of the Root For replacing the data term found at a Web resource with a new data term, XChange offers the following update specification:

in { resource { Res },

Query_Term replaceby Construct_Term }

Update terms specifying multiplicity are not allowed (neither forQuery Term, nor forConstruct Term). The same motivation as for insertion and deletion. As for insertion, if the resourceRescontains data, by applying the following update the data constructed withConstruct Termis to be found atRes(overwriting effect):

in { resource { Res },

var Root replaceby Construct_Term } Example 4.51 (Replacement of the Root)

An update that specifies the replacement of the data term found athttp://sn.dewith the data term found athttp://software.de.

in { resource {"http://sn.de"}, Catalogue {{ }} replaceby var P }

The binding for the variablePis obtained from evaluating the ’condition part’ of the rule having the above update as ’action part’; the Web query of ’condition part’ looks as follows:

in { resource {"http://software.de"}, var P → Products {{ }}

}

On Alternative Approaches to Updating Data with XChange (Discussion) In contrast to existing proposals for update languages for the Web, XChange is a pattern-based language, which shows thatupdate patterns(called update terms in XChange) can be easily specified and understood. XChange takes the philosophy of Xcerpt and applies it to specifying evolution of data on the Web; Xcerpt uses the pattern approach for querying data on the Web – capability needed (as already shown in the previous sections) for updating (persistent) data and for querying (volatile) data. For updating Web data with XChange, alternative approaches have been investigated; this discussion concentrates on these approaches by showing the evolution towards the current update component of XChange.

Following the first approach that has been investigated, the desired updates have been executed directly on bindings for variables returned from evaluating an Xcerpt query. Xcerpt queries are specified as patterns for the data and do not select nodes, but return data terms as bindings for the variables in the query – they are copiesof data terms. Thus, performing updatesdirectly onthe data terms obtained as answers to Xcerpt queries means that only copies of the data are modified; such updatesdo not update(modify) the data. Recall the Example 4.47, which specifies the modification of the used currency from Euro to US Dollar. Consider now the following query term that is needed for binding data terms to variables and modify them afterwards:

in { resource { "http://airline.com" }, flights {{

var Ch ->last-changes { var L }, var Curr -> currency { "EUR" }, flight {{

var P -> price {{ var Price }} }}

}} }