RE: Isolation levels (long and technical)

> I chose to implement the options by means of a user-definded data
> element. This has several advantages over an extension function, not
> the least being portability (an XSLT processor that doesn't recognize
> a user-defined data element must simply ignore it, whereas an
> unrecognized extension function will cause an error). This seems to me
> of great importance for what is essentially an optimization hint - the
> meaning (i.e. the result) of the transformation is the same in either
> case - only the performance should change (although an error might
> result due to exhaustion of resources, but this is true for any
> transformation). of course, portability would be even greater if an
> exslt standard could be agreed.

I see two main problems with this approach. Firstly, your syntax only works
for URIs that are known at compile time. Secondly, I'm not sure it's useful
to specify a distinct isolation level for each resource. In SQL, the
isolation level is a property of a transaction, and that's what I had in
mind by suggesting that there was an analogy here. This would make it a
dynamic concept rather than a static one. Also, the duration of a
transaction can be less than the entire transformation.

Note also that full serializability of transactions requires that you lock
the absence of a resource as well as its presence: if doc-available()
returns false the first time you call it, it must continue to return false
on subsequent calls in the same transaction.

This approach would also avoid the "tricky interaction" you describe below:
> 
> There remains a tricky interaction between the two URI
> spaces. Although the XPATH 2.0 specification does not demand such an
> interpretation (but it certainly doesn't forbid it), I have chosen to
> link the two URI spaces in the following manner 
> 
> For a given file: collection URI, file:///a/b/c/, fn:collection
> assigns a document-uri to each resulting document node of
> file:///a/b/c/file-name.
> If the resulting file: URI is also accessed via fn:doc(), then the
> isolation-levels must be specified compatibly, or else an 
> dynamoc error
> is raised ...
> 
> Finally, testing the implementation shows, as I expected, that setting
> an isolation-level of read-committed results in a slower
> transformation than specifying serializable.

I think this is likely to depend (a) on the implementation, and (b) on the
use case.

Michael Kay
http://www.saxonica.com/