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

["Mike Haarman" <mhaarman@xxxxxxxxxxxxxxxxxx>]

----- Original Message ----- 
From: "Michael Rys" <mrys@xxxxxxxxxxxxx>

Michael,

Thanks for your thoughtful reply.  I hope I can do justice to your request for
more specifics.

I am again posting the xsl-list in the hope that someone better informed than I
can either get my gist and run with it or disabuse me of my misunderstanding.

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

I believe the WG has rather provided a good separate approach than a good
combined approach.

Correct me if I'm wrong, but I don't believe that it is possible to write a
stylesheet that takes advantage of any of the datatypes available to XPath 2.0,
simple or complex, that will operate correctly in both validating and
non-validating environments, without jumping through a few hoops.

To whit, using xs:dateTime.  In order to utilize functions on this datatype in
both validating and non-validating environments without the danger of an
unrecoverable run-time error, I must:

10  test whether datapoint is appropriately type annotated
20  if yes, go to 60
30  if no, test whether data is castable as xs:dateTime
40  if yes, cast and go to 60
50  if no, resort to string pfaffing or throw error
60  fn()

The string pfaffing I would have to do with the current toolset goes in anyway
unless the code just wants to bark.

For all the safety the proposed typing regime provides against delivering or
receiving nonsense, it has a negative impact on coding efficiency if that code
must work within both validating and non-validating environments alike.

Let me say I would like very much to be wrong about this.  Even if I'm right, it
may well be that this is a necessary cost.  I bring it up because I feel it will
have a negative impact on the success of the specification and particularly upon
my own interests, namely XML FUBU (for users, by users).

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

That's good news, Michael, but not great news.  That this is left to
implementors may well create challenges for the portability of the code.

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

Agreed, I did not intend to offend and did not mean to suggest an evil plot.
Only when I think of the gorillas in this industry Microsoft is the first name
that springs to mind.  Allow me to retract the remark and say rather:

There are powerful constituencies in this industry, both corporate and
individual, who have no qualms about XML being perceived as complex, esoteric
and the domain of highly-trained specialists.

I have always found these turf-building types to be personally galling and
professionally an albatross on my efforts to demystify computing for others, as
well as a general hindrance to the progress of software engineering.  In the
domain of XML, their interests run directly counter to what I feel are the most
significant facets of the technology, its openness and its ease-of-use.

Thanks again for your thoughtful reply.  I hope I have clarified my concerns.


Mike

> -----Original Message-----
> From: Mike Haarman [mailto:mhaarman@xxxxxxxxxxxxxxxxxx]
> Sent: Wednesday, May 14, 2003 15:45 PM
> To: xsl-list@xxxxxxxxxxxxxxxxxxxxxx; public-qt-comments@xxxxxx
> Subject: Re: [xsl] Using or ignoring Types in XSLT 2.0 / XPath 2.0
>
>
>
> ----- Original Message -----
> From: "Kurt Cagle - Olywa" <cagle@xxxxxxxxx>
>
> 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@xxxxxxx
>
> > 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



 XSL-List info and archive:  http://www.mulberrytech.com/xsl/xsl-list