Re: W3C-transformation language petition

[Guy_Murphy@xxxxxxxxxx]

Hi. Paul.

Probably wise of you to draw a halt to this thread as it just risks
becomming entrenched.

I wont address you very worthy arguement directly here as it's unfare to
throw an arguement at somebody they aren't going to readdress. I have
addressed the issue in part in a reply to one of Oren's posts if you're
interested.

At the end of the day I think debate on this matter probably accademic as I
feel before long the XSL WG likely to follow a path similar to the one you
suggest and split the current draft into two Recs. Whether the
tranformative part of this then gets subsumed by XQL, or indeed gets split
further into an XQL pattern matching syntax and an XTL construction
description remains to be seen.

Cheers
     Guy.





xsl-list@xxxxxxxxxxxxxxxx on 03/03/99 11:41:03 AM

To:   xsl-list@xxxxxxxxxxxxxxxx
cc:    (bcc: Guy Murphy/UK/MAID)
Subject:  Re: W3C-transformation language petition




As my last post on this subject let me say that standards creation is
software engineering. A central principle of software engineering is that
functionality that can be independently reused should be factored out so
that independent reuse is possible. This factoring is the foundational of
all robust information systems.
The arguments against this factoring that I have heard here and elsewhere
are not technical: they are political. You are the one playing "marketing
games."
>I   continue to maintian that styling *is* transformation and
> formatting, and that the two parts are therefore requesite for a
> styling language
Nobody claims otherwise. But the transformative part is independently
useful and should thus be factored.
> And if you want an XTL or whatever all power to you, but
> please, do you have to insist on doing it by stepping on the head of XSL?
The alternative is to *duplicate* the features of the transformative part
of XSL. That is poor software engineering and poor standards creation.
> Isogens, or Activateds or
ISOGEN does not make parsers. ISOGEN does not market XSL. ISOGEN builds
information systems based on industry standards. Our customers need an
XSL-like transformation language. The choices for creating one are
factoring or duplication. One is good standards engineering practice. The
other is not. It is not a tough choice.
> whoevers parser can claim to support FOs in as
> far as they can be produced from the parser, not being a user agent there
> can be no expectation that the parser actually render the FOs ::shrug::
> seems to make the above two points obsolete.
You are out of sync with the XML specification:
"When the result tree uses the formatting vocabulary, a conforming XSL
implementation must be able to interpret the result tree according to the
semantics of the formatting vocabulary as defined in this document; it may
also be able to externalize the result tree as XML, but it is not required
to be able to do so."
Merely outputting the XML objects is not "interpreting" them.
It is pretty clear by now that you are willing to let your love of XSL
drive everything even if it leads to poor standards engineering in the
rest of the W3C family of standards. I think that the working group will
be more far-sighted.
--
 Paul Prescod  - ISOGEN Consulting Engineer speaking for only himself
 http://itrc.uwaterloo.ca/~papresco
"The Excursion [Sport Utility Vehicle] is so large that it will come
equipped with adjustable pedals to fit smaller drivers and sensor
devices that warn the driver when he or she is about to back into a
Toyota or some other object." -- Dallas Morning News

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






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