RE: [xsl] Using or ignoring Types in XSLT 2.0 / XPath 2.0

Dear Mike 

Thanks for your comment. But I have to ask you to give us a bit more
concrete examples where you think the typing is giving you problems and
what range of XPath 2 functions display problems for you. 

Given that XSLT provides for a conformance level that is without typing
and given that we work hard to provide week typing on untyped data and
strong typing on typed data, I think we aim to provide a good combined
approach. 

The type annotations in the data model can occur in any way that satisfy
certain integrity constraints. They do not have to involve validation,
although often they will.

So while I appreciate philosophical discussions on this topic, we need
actional feedback and not philosophical design discussions at this
stage.

Best regards
Michael

PS: I am not sure I should take the flame bait about Microsoft, but I
can assure you that there is no evil Microsoft plot behind adding typing
to XPath/XSLT. Such comments don't help making your point...

> -----Original Message-----
> From: Mike Haarman [mailto:mhaarman@infinitecampus.org]
> Sent: Wednesday, May 14, 2003 15:45 PM
> To: xsl-list@lists.mulberrytech.com; public-qt-comments@w3.org
> Subject: Re: [xsl] Using or ignoring Types in XSLT 2.0 / XPath 2.0
> 
> 
> 
> ----- Original Message -----
> From: "Kurt Cagle - Olywa" <cagle@olywa.net>
> 
> Hey all,
> 
> I recognize that the typing debate is quickly approaching perma-thread
> status on
> XML-DEV and I did not intend to start that pillow fight over here.
Better
> and
> better informed minds than mine have been chewing on this for some
time,
> but now
> is the time to make my voice heard, if it is to be heard at all, and
this
> reply
> has been cross posted to public-qt-comments@w3.org.
> 
> > I still contend that type doesn't belong in XSLT, but if it is in
there,
> it
> > should make processes more efficient, not less. If type needs to be
> there,
> > then all of XSD should be supported, such that an XSLT function can
> return
> > an object of complex type Foo.
> 
> I concur.  Two points to note:
> 
> 1) A range of XPath 2 functions display indeterminate behavior in the
> absence of
> PSVI type annotation.  I believe this practically voids their utility
for
> a very
> large set of XML applications, that is: web-facing ones.  Validation
> remains far
> too expensive for non-trivial network applications.  We validate
coming
> in, but
> we can't afford to validate going out.  Validation is a useful tool,
but a
> glaring inefficiency.
> 
> As a consequence of this practical consideration, typing offers little
> value for
> us.  We will continue to rely on Java adaptors to wrap the results of
our
> SQL
> statements in well-formed XML 1.0 for presentation.  Business logic
will
> continue to live largely in SQL statements and Java classes where
typing
> is
> managed in their conventional ways.
> 
> The pfaffing of strings (love that word, Andrew) will continue, but
has
> never
> been a particular burden.  I wrote a lovely universal calendar,
porting a
> day-of-week algorithm from C to XSLT and the sum of string pfaffing
> consisted of
> three substring functions; a v2 of this stylesheet will still use
three
> functions to get what I need, but three discrete functions on dateTime
and
> a
> test and a cast in the absence of validation.
> 
> 2) A consequence of this reliance on validation-driven type annotation
is
> to
> effectively deprecate well-formedness in XML processing.  X(Path|SLT)
2.0
> does
> not represent an evolutionary step.  Developers and architects cannot
> simply
> decide to use 2.0 because "it's the latest".  It is a revolutionary
change
> that
> implicates other choices.  It is a paradigmatic shift, not a
generational
> one
> and entails validation.
> 
> This is where political and philosophical considerations enter.  I
think
> that
> the drafts as currently constituted are a death sentence for userspace
> XML.
> Whether you think that is a problem is, as I say, a political issue.
> Microsoft
> loves the idea of obfuscating XML to the point of inutility and the
> complexity
> of XSD is just one facet of their push to stub out userspace XML.
> 
> I feel strongly that XSL is currently a valuable userspace tool.  This
is
> at
> least partly a consequence of the relative absence of datatyping.  The
> essential
> goal of XML, to my mind, was to get data and process out of the binary
> silos,
> out of the hands of ISVs and developers and into the hands of users.
> Userspace
> XML is a three-legged stool and the application support and training
legs
> have
> long been broken.  Deprecating well-formedness as the current drafts
> effectively
> do leaves us sitting on the floor.
> 
> If xdt:untypedAtomic is the gesture intended to decouple type
annotation
> from
> validation, it does not go far enough.
> 
> The current drafts try to strike a balance but to no purpose.  In the
> world
> projected by the May 2 drafts, there are effectively two different
species
> of
> XML, not two flavors; the two cannot relate directly from the
point-of-
> view of a
> stylesheet author.  A stylesheet that behaves as expected over one
will
> not
> necessarily behave the same over the other, including the possibility
of
> run-time failure.  Validated XML and that which is merely well-formed
will
> each
> require distinct XSL programming idioms.
> 
> The drafts should be adapted to reflect this distinction.  I feel
strongly
> that,
> at the least, functions with unsafe behavior in the absence of PSVI
type
> annotation must be noted in the specification.  It would be better
still
> to
> accommodate the type annotation of XML data external to validation.
Best
> of all
> would be to acknowledge that type-annotated XML is a separate and
distinct
> beast
> with its own infoset; from an XSL perspective, it already is.
> 
> 
> Sincerely,
> 
> Mike Haarman,
> Developer and Information Architect,
> Infinite Campus

Received on Wednesday, 14 May 2003 22:46:03 UTC