[
Lists Home |
Date Index |
Thread Index
]
> 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
b) based on a named type system
c) a and/or b only as provided within a schema
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". 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 can extend the original dynamic system with a static axiom
that all occurences of "$i//item/price" must be integers upon parsing. Hell,
Schematron can manage that with a REGEX extension function, never mind WXS.
If you start with static typing as the sole vision, you pretty much cripple
dynamic constriants. They have no standing in the formal model, so how do I
express my dynamic constraints in an XQuery function definition?
b) There is no reason it has to be named types. The constraints that are used
to improve the design or implementation of the function, whether static or
dynamic can be "ad-hoc", declared in some constraint language (REGEXen are one
example, RELAX NG is another) and made to be first-class constructs in the
language, i.e. they can themselves be passed to functions and such.
c) Even if one were to say "XQuery requires static, named types" (I personally
could readily accept named constraints, but static types are beyond the pale
of evil to me) then the question remains, why do these *have* to be provided
in a schema? Why not divorce XQuery's typing semantics from the underlying
parsing and pre-query processing? Why not just say "the XQuery implementation
must provide so and so static type information and so and so type inferencing
functions" and leave it at that? Why mandate that these come from the PSVI?
--
Uche Ogbuji Fourthought, Inc.
uche.ogbuji@fourthought.com http://fourthought.com
http://4Suite.org http://uche.ogbuji.net
Track chair, XML/Web Services One (San Jose, Boston):
http://www.xmlconference.com/
RDF Query using Versa - http://www-106.ibm.com/developerworks/xml/library/x-thi
nk10/index.html
WSDL and the Wild, Wild West - http://adtmag.com/article.asp?id=6004
XML, The Model Driven Architecture, and RDF @ XML Europe -
http://www.xmleurope.com/2002/kttrack.asp#themodel
|
