[XML-DEV Mailing List Archive Home] [By Thread] [By Date] [Recent Entries] [Reply To This Message]

Re: W3C's five new XQuery/Xpath2 working drafts - Stillmissin

• To: Jonathan Robie <jonathan.robie@s...>,"Champion, Mike" <Mike.Champion@S...>, xml-dev@l...
• Subject: Re: W3C's five new XQuery/Xpath2 working drafts - Stillmissing Updates
• From: Paul T <pault12@p...>
• Date: Thu, 27 Dec 2001 14:24:12 -0800
• References: <5.1.0.14.0.20011227082828.02cef1a0@s...>

> Is it valid to multiply an integer times an element whose content is an
> integer? Is it valid to multiply an integer times an element whose content
> is a string? Is it valid to multiply an integer times an element whose
> content is a URL? If we have introduced a system that manipulates
instances
> of types, we need a type system that tells us which operations are valid
on
> a particular instance.

It is interesting how would your 'type' system finally look like.
If  we have 'Integers' and 'Strings', then we should have 'floats',
'doubles', 'dates' e t.c.. But all this stuff is applicable to scalars only.
XML is more interesting, because it allows for sets, arrays and  maps.
( of floats, dates , doubles, integers e t.c. )

And the funny thing is that all this stuff is not really needed,
because what people need in everyday coding is actually
a *constraints*  system, but not a types system.

> If I perform a query on an XML message to create XML content to be stored
> in a database, a type system can guarantee that the result will conform to
> the schema of the database. I think we need to have that kind of
guarantee.
> Whether or not we have a type system, we do have types, and if the wrong
> kind of data is generated, we hope it will be rejected. When possible, I
> would like to have that guarantee statically so that I know it will
> *always* conform to the schema of the database, because testing is never
> exhaustive, and my tests just might miss important cases that cause
> problems. This is always advantageous, but it is especially advantageous
> when we add updates to XQuery.

Agree. 100%. For an XML database / repository it is very important
that update or insert or delete would not screw the schema, because,
for example, by mistake in a query, developer may try to append at
attribute or an element to  some 'wrong' place and that'l be a mess to
capture
and 'remove' 'later', so it should not make it into the database first of
all.

This is really important thing.

However, it appears that ( at least for SQL and I can not see
why it should be different for XML ) you don't need
no type systems for that, but the better constraints system
you have - the better. By 'better' constraints system I mean
that not only one should restrict the position of attribute,
but it would be nice to validate if the value of attribute is correct
*from the business rules perspective* or if it is in sync
with other parts of the database ( 'foreign key'  e t.c.).

No types involved ( because there is no possible 'type'
system that can ever do the  validation that is *really*
required).

> XPath 2.0 already contains the vast majority of XQuery. The main
> differences involve element construction and strong typing.

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.

> But queries also need to be able to construct instances, especially if you
> have updates.

Exactly. 100% agree.

> Suppose I want to add a new book to a bibliography, before an
> existing book. I would like to be able to do an update like this:
>
> update
>    let $b := document("data/xmp-data.xml")//book[title="TCP/IP
Illustrated"]
>    insert
>          <book year="1997">
>              <title>Java in a Nutshell</title>
>
<author><last>Flanagan</last><first>David</first></author>
>                  <publisher>O'Reilly</publisher>
>                  <price>29.95</price>
>          </book>
>    before $b

 insert before
    document("data/xmp-data.xml")//book[title='TCP/IP Illustrated' ]
value
    book [ year="1997" ] {
              title { "Java in a Nutshell" }
              author {
                    last { "Flanagan" }
                    first { "David" }
              }
            publisher{ "O'Reilly" }
            price{ "29.95" }
    }

> Without element construction, we can't do that. Also, I need element
> constructors when I replace existing data:

update
    document("data/xmp-data.xml")//book[title="TCP/IP Illustrated"]
value
    book [ year="1997" ] {
              title { "Java in a Nutshell" }
              author {
                    last { "Flanagan" }
                    first { "David" }
              }
            publisher{ "O'Reilly" }
            price{ "29.95" }
    }

> Now suppose this document is governed by a schema. Should this update be
> allowed if the new element does not conform to the schema? If the schema
> specifies default attributes, should the new instance contain those
> attributes?

All valid questions.

> What is the type information associated with the new instance?

This question looks like a bit different  story, even it looks very
much similiar to the valid questions, asked before.

> 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?

> Having written quite a few queries, and several function libraries, I
would
> 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.

Rgds.Paul.

PS. I don't expect your answer, because you're on vacation.
Perhaps somebody who is not on vacation can explain what
is going on with 'XML types'. Is there one more useless 'standard'
from W3C on it's way?  I guess 'Complex type system for XML'
may sound appealing to some CEOs and PHBs, but is there any
technical value in the 'XML types' ?

• Follow-Ups:
  • Re: W3C's five new XQuery/Xpath2 working drafts - Still missing Updates
    • From: "Dare Obasanjo" <kpako@y...>

• References:
  • RE: W3C's five new XQuery/Xpath2 working drafts - Still missing Updates
    • From: Jonathan Robie <jonathan.robie@s...>

• Prev by Date: RE: W3C's five new XQuery/Xpath2 working drafts - Still missing Updates
• Next by Date: Re: W3C's five new XQuery/Xpath2 working drafts - Still missing Updates
• Previous by thread: Re: W3C's five new XQuery/Xpath2 working drafts - Still missing Updates
• Next by thread: Re: W3C's five new XQuery/Xpath2 working drafts - Still missing Updates
• Index(es):
  • Date
  • Thread