Lists Home |
Date Index |
----- Original Message -----
From: "Paul T" <email@example.com>
To: "Jonathan Robie" <firstname.lastname@example.org>; "Champion, Mike"
Sent: Thursday, December 27, 2001 2:24 PM
Subject: Re: [xml-dev] W3C's five new XQuery/Xpath2 working drafts - Still
> I think typing is not needed. I think it would be a wrong direction
> from technical perspective. XML can not cure the world's hunger
> and provide a types system that would fit all existing languages.
> I think you're absolutely right that the element construction is really
> unavoidable. The syntax for element construction ( for updates / inserts )
> is actually questionable, because it may be more convinient to use
> non-xml-ish syntax, when constructing the element, see
> the invariant below.
I prefer XMLish syntax for element construction. The less unnatural syntax
developers have to learn the better. One of the goals of XML used to be that
verbosity and not terseness was encouraged, I don't see any reason to change
that now especially when in the midst of a language as complex as XQuery.
> > If this update is really modifying your mission-critical data, I think you
> > probably want to ensure that updates are not creating invalid data.
> Sure. And you would not like to get a wrong or duplicate
> isbn e t.c. And the best way to ensure the robustnes of the system is :
> constraints + validation, based on business rules
> Where are types?
I agree that types are unnecessary for modifications involving the
construction of new elements or attributes and inserting them into the
repository but can can see the need for some notion of types when queries
involve expressions that operate on multiple types (E.g. what is the result of
multiplying an attribute of xsi:type nonNegative integer with a negative
number and adding it to an element of xsi:type dateTime then trying to insert
it into an element of xsi:type byte?). At what stage should the processor
complain and what should be passed to the underlying XML repository? Of
course, all this complexity could be avoided if XQuery was not based on a type
system as complex as XML schema and instead used something similar to the
model used in XPath 1.0 (I'm unfamiliar with 2.0 and don't know if it is the
type system is the same or has "evolved").
> > Having written quite a few queries, and several function libraries, I
> > say that a significant number of errors can be caught by the type system.
> Like... with the queries written above, for example?
> What is the type system that would allow catching the bugs,
> if developer provides some 'wrong' data with the queries,
> written above? I don't get it.
From reading the section on data and types in the XQuery Formal semantics
it looks like the type system involved is XML schema. The W3C wants XQuery
to be schema aware instead of relying on constraints and validation in the
underlying XML repository. Thus XQuery expressions like the ones above can be
validated for correctness before even touching the underlying XML repository
as long as the schema for the data/xmp-data.xml file is available (slight
exagerration here, since it'll have to touch the repository to determine the
schema for the document). As I mentioned elsewhere, this allows for more
uniformity in the behavior of applications that utilize XQuery but is NOT
necessary to have updates in XQuery.
PS: The above comment is just conjecture on my part from reading the available
THINGS TO DO IF I BECOME AN EVIL OVERLORD #231
Mythical guardians will be instructed to ask visitors name, purpose of visit,
and whether they have an appointment instead of ancient riddles.
Do You Yahoo!?
Get your free @yahoo.com address at http://mail.yahoo.com