[xquery-talk] XQuery question

[Michael Kay]

XQJ as implemented by Saxon can be a bit confusing because the terminology
doesn't always match. XQJ was designed around the conceptual framework of a
client-server database, which Saxon is not; as a result, for example,
Saxon's implementation of XQDataSource does not actually hold any data, and
Saxon's implementation of XQConnection does not actually involve indepedent
client and server processes. Nevertheless, XQJ is specified in sufficiently
abstract terms that it is possible to map all the concepts onto something
that Saxon provides. However, if you want to avoid such conceptual overload,
using Saxon's own s9api interface may be easier (as well as exposing more of
Saxon's functionality).
 
XQJ tends to assume that when you connect to a DataS ource, that will give
you access to some preloaded, prevalidated, persistent data, and it regards
all the processes for creating and loading that database as being out of
scope. Which is just as well when you are using XQJ with a non-persistent
query implementation like Saxon.
 
With Saxon, there are two ways you can supply source documents. You can
either read them from within the query using the doc() or collection()
functions, or you can supply them as parameters to the query using a method
such as XQDynamicContext.bindDocument() or
connection.createItemFromDocument(). In both cases the rules for how this
works are in section 14.3 of the spec (I'm referring here to the PFD version
of the spec, which differs slightly from the version implemented in Saxon
9.0). The methods take an XQItemType argument, and if this is set to
XQITEMKIND_DOCUMENT_SCHEMA_ELEMENT, then the document will be strictly
validated; in other cases it will be untyped. If you request validation and
the product is not schema-aware, an exception is thrown.
 
With Saxon, if you read documents using doc() or collection() then the
validation is determined by configuration settings. In Saxon 9.1 (coming
soon) you'll be able to do XQDataSource.setProperty("schemaValidationMode",
"strict"). In 9.0 it's a bit more clumsy: you can cast the XQDataSource to a
SaxonXQDataSource, call the getConfiguration() method, and then use Saxon's
native API for setting configuration options.
 
The type system of XQuery, and the design of XQJ, are very much tied to XML
Schema. There's some abstraction of the concepts, but in practice, there's
no other validation language that attempts to assign types to nodes in the
way that XSD does. You can always use any technology you like for validating
documents before you query them, of course, but if you want the query to be
type-aware, then you're going to have to use XSD.
 
>If XQJ chooses to be non specific to the XSD schema, how does the saxon use
of createSchemaElementType (that appears to associate the XML file to the
XSD) differ to what is proposed by the JSR ? 
 
I think Saxon's implementation is entirely consistent with what XQJ
specifies. XQJ of course allows a range of strategies, for example an
implementation might require all schemas to be preloaded in the database,
but this method is designed to allow schema information to be loaded on
demand and that's what Saxon does.
 
>From what I can see XQJ does specify  XQSequenceType and XQItemType. Am I
right in thinking these are similar but not the same as XSD types ?
 
Yes. I think it's unfortunate that the W3C specs have a single diagram
showing both sequence types and schema types as if they form a single
hierarchy (and XQJ reproduces this), when in fact they are related but
distinct. Every XPath/XQuery value conforms to a Sequence Type (of which
Item Types are a subset). Elements and attributes are validated against a
Schema Type (which may be a simple type or a complex type). Atomic types are
the same in both systems, but apart from that they are disjoint. Schema
types break down into Complex (with complex or simple content) and Simple
(list, union, or atomic), while Item Type break down into node types
(element, attribute, comment, text etc) and atomic types. When you validate
an element E against the complex type T, the item type of the resulting
element is element(E, T).
 
>Can I provide type for my XML elements, attributes etc outside of an XSD
using XQSequenceType and XQItemType ?
 
If you're not using a schema, the only types available are the generic types
such as xs:untyped and xs:untypedAtomic. Theoretically an XQJ implementation
could provide an alternative way of defining type information for incoming
nodes, but Saxon certainly doesn't attempt to do so. The DataDirect
implementation gives you access to virtual nodes that are a view of rows in
your SQL database, and these have type information derived from the SQL
schema; XQJ is flexible enough to accommodate that.
 
Michael Kay
http://www.saxonica.com/ 



  _____  

From: talk-bounces at x-query.com [mailto:talk-bounces at x-query.com] On Behalf
Of Naveen hanumara
Sent: 27 June 2008 04:19
To: talk at xquery.com
Subject: [xquery-talk] XQuery question


Hi, 

I'm new to xquery and have been trying to understand the XQJ implementation
and also how saxon tackles it. I am aware saxonA is schema aware.
What is the requirement of XQJ as far as validation is concerned ? I
understand it is open as far as validating XML and doesn't tie down to one
format such as XSD.
If XQJ chooses to be non specific to the XSD schema, how does the saxon use
of createSchemaElementType (that appears to associate the XML file to the
XSD) differ to what is proposed by the JSR ? 

>From what I can see XQJ does specify  XQSequenceType and XQItemType. Am I
right in thinking these are similar but not the same as XSD types ? Am I
right in thinking the schema aware
version of Saxon has mapped the XSD type to the variations within
XQSequenceType and XQItemType ?

Can I provide type for my XML elements, attributes etc outside of an XSD
using XQSequenceType and XQItemType ?

Thanks,
Nav




-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://x-query.com/pipermail/talk/attachments/20080627/730ed10a/attachment.htm