[
Lists Home |
Date Index |
Thread Index
]
----- Original Message -----
From: "Jonathan Robie" <jonathan.robie@softwareag.com>
To: "Dare Obasanjo" <kpako@yahoo.com>; "Champion, Mike"
<Mike.Champion@SoftwareAG-USA.com>; <xml-dev@lists.xml.org>
Sent: Friday, December 28, 2001 9:07 AM
Subject: Re: [xml-dev] W3C's five new XQuery/Xpath2 working drafts - Still
missing Updates
> First off, I think that XQuery *is* involved if XQuery is the language used
> for updates. If XQuery does not have a notion of which updates are allowed,
> then I do not think that XQuery should be used to perform the updates. If
> XQuery does not understand the schema of an XML instance, it has no
> business mucking with the XML data in ways that might lead to invalid
results.
I guess we are just going to have to agree to disagree.
SQL has no notion of schemas but has updates and I've yet to see complaints
about this being a failing of SQL. Also having XQuery become schema aware will
not change the fact that updates involving identity constraints (i.e
xs:unique, xs:keyref, etc) will still need to query the underlying repository
before they can be shown to be type valid.
> The definition of type validity could be done in terms of schema
> validation. In fact, for dynamic typing, that's probably the right way to
> do it. The first generation of XQuery processors that support update might
> even use schema validation for this purpose. Static typing can not be done
> in terms of schema validation, for the simple reason that XML Schema does
> not validate a type result against a schema.
>
> As for your performance question, it is generally faster to determine that
> a query is not valid before executing it. Looking at the data is expensive.
I wasn't suggesting executing the query before determining if the query was
valid but more like suggesting that the validation of the query is done by the
underlying repository (if necessary) and not required of the XQuery
engine/processor/whatever.
> >I agree that element construction is necessary for updates but I'm
unconvinced
> >that *strong* typing is necessary, after all Perl is as weakly typed as
they
> >come but this hasn't precluded its use as a language for use in programming
> >against RDBMSs which have a rather strong notion of types.
>
> Personally, I have been rather frustrated that the tools I use to create
> XML do not know whether they are creating valid XML. For instance, I have
> written a lot of XSLT stylesheets that create HTML, and there are no tools
> that can tell me whether a stylesheet will always create valid XHTML by
> looking at the input DTD and the XHTML DTD. In fact, I have stylesheets
> that I have used for years, and when I create a new XML source, I find that
> I have to fix the stylesheet because there are constructs that had not been
> adequately tested by other documents I had written.
> In an e-business environment, it is frequently necessary to extract
> information from a message that is governed by one DTD and create XML
> governed by another DTD. Some of these messages may contain patterns of
> data that the programmer of a query was not expecting. We want to catch
> errors as early as possible, and not wait for new XML documents to expose
> our bugs after a system has already been deployed.
>
> Also, if we have weak typing, the rules for weak typing also must be
> defined. In our current documents, we have done that using the fallback
> rules in XPath 2.0 - and these rules are defined in terms of the rules for
> strong typing.
>
I recently read a paper entitled "On Database Theory and XML"[0] by Dan
Suciu[1] of the university of Washington where he states that static XML
typechecking of Java/C++/etc programs generating XML documents is undecidable
due to Rice's Theorem.
He also mentions "type inference" where type inference refers to the process
of generating a schema based on XML generated by a script or query language
which can then be used to determine whether the generated XML always conforms
to a specified schema.
He then states that "type inference" is not possible even for the simplest
subsets of query languages including XSLT and XQuery. So unless I am mistaking
his conclusions, he stated that your above problem cannot be solved regardless
of whether your query/scripting languages have a knowledge of types or not..
> >The most significant errors that DBMSs usually catch in my experience have
> >been constraint related (foreign keys, uniqueness, non-null, etc) and not
> >really type related.
>
> XML has a much richer structure, giving lots of opportunities for other
> kinds of errors. Here are some kinds of errors that I have made that are
> type errors:
>
> 1. Confusing a URI with the resource it identifies.
> 2. Forgetting the {} in an element constructor:
>
> <count> count(//product) </count>
>
> The expected type is integer, but the actual type is untyped character
> data.
> 3. Creating an element whose content does not match the content model in
> the schema.
>
> I could make a longer list, but I think you get the picture. These are
> common errors. I would rather have the query system tell me what I did
wrong.
:)
This is still information that can be handled by the underlying XML
repositories instead of strictly enforcing them in the query language and thus
precluding the usage of other schema languages like DTDs, XDR, SOX or RELAX NG
with XQuery.
Thus the W3C is basically forcing anyone that plans to use XQuery to also use
XML schemas, which I am not 100% sure is a step I am comfortable with.
> I think that the Schema Adjunct Framework is useful as a basis for this
> kind of functionality:
>
> http://www.extensibility.com/resources/saf_dec2000.htm
>
I looked at it and seemed interesting. A generic framework for specifying
post-schema processing for documents is interesting and I can see some
applications for it. How close is this to becoming something official?
PS: I've submitted some comments to the XQuery WG, so far no replies.
[0] http://www.cs.washington.edu/homes/suciu/files/_F2066943700.ps
[1] http://www.cs.washington.edu/homes/suciu/
--
THINGS TO DO IF I BECOME AN EVIL OVERLORD #18
I will not have a son. Although his laughably under-planned attempt to usurp
power would easily fail, it would provide a fatal distraction at a crucial
point in time.
_________________________________________________________
Do You Yahoo!?
Get your free @yahoo.com address at http://mail.yahoo.com
|
