[
Lists Home |
Date Index |
Thread Index
]
> > -----Original Message-----
> > From: Uche Ogbuji [mailto:uche.ogbuji@fourthought.com]
> > Sent: Wednesday, July 03, 2002 1:48 PM
> > To: Jonathan Robie
> > Cc: Simon St.Laurent; xml-dev@lists.xml.org
> > Subject: Re: [xml-dev] XQuery and DTD/Schema?
> >
> > a) There is no reason it has to be static.
>
> i.) Static types improve performance and help catch errors in many
> cases.
I accept that static typing can sometimes make it marginally easier to optimize code. I disagree that this is a significant advantage, because the 80/20 rule means that most of the things that truly need to be optimized are beyond the reach of static typing magic, anyway.
I emphatically do not accept that static typing improves safety. I have argued many times that static typing covers far too tiny a sliver of the spectrum of typical programmer error to make a significant improvement. I can tell you from my personal experience that the defect rate in the code I wrote has gone noticeably down since I started doing most of my programming ina language that does not support static typing.
And the reason this is so leads to the reason I call static typing not only overrated, but evil. Static typing impedes expression. The semantics of your code, and how it maps to the real world are put into a straitjacket by language designers who certainly did not have you particular slice of the real world in mind when they did their bit. The inevitable result is that you end up writing more brittle work-arounds to the limits imposed by the static typing system.
By providing more richness of expression, dynamic typing systems IMO improve safety by making it easier for people to write code that is a natural analog to the real world.
> However, the XQuery type systemin some cases costs more than the
> benefits it brings,
>
> ii.) If you don't like static types then don't use a schema or static
> type related constructs. The problem however is that if static types are
> made mandatory then queries which may work such as
>
> /foo[@bar < 5]
>
> will fail at compile time which may be rather unsatisfactory.
This is why I say it is easier to add static typing to a fundamentally dynamic system, if it proves necessary, than the other way round.
> > so how do I
> > express my dynamic constraints in an XQuery function definition?
>
> What dynamic constraints would you like to express?
There's a wide open barn door. Just to pluck one random example off the top of my head: what if I want to constrain a date value to come before the date upon which the query is made?
> > b) There is no reason it has to be named types.
>
> You need a mechanism to specify constraints on the arguments to various
> functions and operators. Whether you decide to name them or keep them
> anonymous doesn't make much of a difference although I'd prefer named
> types for usability reasons.
As I mentioned, I'm not as passionate on this point. I agree that named typing can be a convenience of expression. I think my main concern, and the strong concern of others, is that the names of WXS types are not just a convenient tag, but a fundamental part of the semantics of the type, which end up blocking out the XML 1.0 constructs on which the "type" is founded.
> > c) Even if one were to say "XQuery requires static, named
> > types" Why mandate that these come
> > from the PSVI?
>
> This is not mandated. This is why there is a mapping from the PSVI to
> the XQuery data model in the first place.
I've read quotes in this thread that seem to say PSVI is king for XQuery, and I've also read denials of this. It's not a point on which I'm informed for argument, so I'll leave off.
I guess we're mostly down to my personal Lucifer: static types :-)
--
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/library/x-think11.html
|
