[
Lists Home |
Date Index |
Thread Index
]
> At 02:47 PM 7/3/2002 -0600, Uche Ogbuji wrote:
> > > Let me try to explain why I think named typing is good. Here's a function:
> > >
> > > define function get-total( element invoice $i )
> > > returns xs:decimal
> > > {
> > > sum( $i//item/price )
> > > }
> > >
> > > This function assumes that the invoices it takes have been validated as
> > > invoice elements according to some schema, and are not merely well-formed
> > > elements whose name happens to be 'invoice'. At run-time, you don't
> > want to
> > > have to test every function parameter to see if it corresponds to a
> > schema,
> > > you simply want to ensure that the validator has said this corresponds to
> > > the appropriate definition.
> >
> >You keep saying this sort of thing, and it baffles me. Its a solution in
> >search of a problem if I ever saw one. If the substrate data is *XML* (this
> >is what we're here to discuss, right?) then why do these declaration have
> >to be
> >
> >a) static
>
> Static typing is not required in XQuery. If you choose to use static
> typing, it can guarantee that the above function will only be applied to
> invoices that have been validated according to the schema used for static
> typing. If you do not choose to use static typing, then dynamic typing is
> used.
>
> Here are some quotes from the XQuery spec:
>
> At user option, static typing can be disabled. A query that
> passes type checking will return the same result regardless of
> whether type checking is enabled or disabled. [Ed. Note: See
> Issue 41 for a further discussion of static vs. dynamic
> semantics.]
OK, since you have this provision, why does it not inform the architecture of
XQuery itself? Why not have a modest specification that just presents the
basic data model and syntax of XQuery based on WF XML. Then have an adjunct
specification which discusses the effect of using XQuery on instanes with TAIs
(or other means of providing type information)? This would make the
specification much easier to digest (I'd argue for both people who do or do
not use WXS types), and it would certainly make the spec less controversial
and more likely to be widely implemented.
After the last round of XQuery debates I actually made an extravagant (for me)
effort to read and comprehend the XQuery specs. Not only did I not have a
chance because of their sheer bulk, but the extreme confutation of concepts
within the spec makes it impossible to grasp one point and keep it in your
head for when you need it the third following page.
Layering would certainly help here. I could understand the foundation layer,
and understand it deeply, and then venture on to see how other layers of
XQuery features aygmented the basics.
> XQuery is likely to have multiple conformance levels. There
> may be a conformance level that does not include static type
> checking. There may be a conformance level that does not
> support Schema import, so that only built-in types and node
> types may be used in declarations. [Ed. Note: See Issue 42 for
> a further discussion of conformance levels.]
Good. I think, then the crux of the matter will be how the conformance levels
are expressed.
> >c) a and/or b only as provided within a schema
>
> This is not true - any process can create an instance of the data
> model. We take responsibility for showing how to do this with DTDs and
> merely well formed documents, as well as for XML Schema. I don't think we
> have the time or the responsibility to do this for every possible data source.
You say this here, but here is what you said in the message that immediately preceded this one:
"...this is why type annotations are part of
the XQuery data model. They tell the query processor which schema
definitions were used for validation."
You've made many such statements which seem to confirm the tight coupling between schema and XQuery. If what you say in this message is true, it would be good to make that consistently clear.
> >a) There is no reason it has to be static. The semantics of sum can be
> >"accept or convert to an integer". This is how XPath 1.0 does things. And
> >I'll make the technical point that you know very well Simon has made enough
> >times: this is the way to do it that is more cleanly layered for XML
> >processing. I know you'll respond "but that's inefficient".
>
> Efficiency matters, but type safety is at least as important. I don't think
> that type safety is something that should be left to the programmer.
As a programmer, I think I could find this quite condescending. There is no automated system in the world that can relieve a programmer of the responsibility for safety. I've already pointed out that so-called "type safety" is IMHO rubbish. I'm surprised to see the claims for idea taken as far as you seem to in the above.
> >This is an
> >*implementation* matter, and not a matter that should impose itself in the
> >formal semantics. There are many possible strategies for dynamic
> >optimization. And if these do not prove sufficient, static constraints
> >can be
> >*added on*.
>
> You really do have to design a type system for static analysis if you want
> it to work well in this way. A type system is not something you can add on
> in a casual manner.
I strongly disagree. Perhaps because of the effort which you and your colleagues happen to have put into soldering a static, named type system into XQuery, you can't imagine how it could have been done any other way. I have a very different perspective.
> This is precisely what we have done, in fact. We do provide the PSVI
> mappings to the data model. After that, everything is defined in terms of
> our type declarations and the data model representation. To support a
> different system, you have to define your own mappings.
Good, but again, this should be clearer in the specs, and in the discussion of the specs by those who should know them best.
--
Uche Ogbuji Fourthought, Inc.
http://uche.ogbuji.net http://4Suite.org http://fourthought.com
Track chair, XML/Web Services One Boston: http://www.xmlconference.com/
The many heads of XML modeling - http://adtmag.com/article.asp?id=6393
Will XML live up to its promise? - http://www-106.ibm.com/developerworks/xml/li
brary/x-think11.html
|
