Re: Error recovery

On 05/12/2012 08:37, James Clark wrote:
> I don't think it's nearly as bad as "cannot be queried or
> constrained". To make this concrete, let's suppose the recovery
> process produces a tree in which some element names contain $, but
> that your schema or query language syntax does not allow you to write
> an element name containing $.  This means you cannot query
> conveniently for an element containing $,


Perhaps. It could certainly be specified that way if it was specified
but one could argue that currently (for Xpath 2 say) the XDM document
model doesn't require that it is built from an XML parser so you could
build an instance from an error correcting micro-xml parser, but I think
it is a constraint on the document model that XPath implementations are
allowed to, and may actually, rely on that element names match the Name
production. So an implementation could just reject the whole tree if it
contained such names.

It isn't just that you can not refer to <$a> in a step as /$a that isn't
so bad /* would do most of the time, it is return values for
node-name(*[1]) it needs to be specified somewhere whether that's an
error or whether it returns a value but that the type xsd:QName is
effectively extended or.... similarly does
<xsl:element name="{name()}">
generate <$a> or throw an error?

(I know I'm not telling you anything you don't know but still:-) opening
up the data model has repercussions that are not impossible or even
necessarily hard to specify but don't just automatically happen without
specification as there are choices that need to be made.

David


________________________________________________________________________
The Numerical Algorithms Group Ltd is a company registered in England
and Wales with company number 1249803. The registered office is:
Wilkinson House, Jordan Hill Road, Oxford OX2 8DR, United Kingdom.

This e-mail has been scanned for all viruses by Star. The service is
powered by MessageLabs. 
________________________________________________________________________

Received on Wednesday, 5 December 2012 10:34:33 UTC