RE: XSL Requirements (was: Microsoft extensions to XSL)

See below.

-----Original Message-----
From:	Oren Ben-Kiki [SMTP:oren@xxxxxxxxxxxxx]
Sent:	Sunday, November 15, 1998 6:12 AM
To:	xsl-list@xxxxxxxxxxxxxxxx
Subject:	XSL Requirements (was: Microsoft extensions to  XSL)

 Ed Nixon <ed.nixon@xxxxxxxxxxxxxxxxx> wrote:
>I think this might be the point at which we could sit back and take a look
>(again?) at the requirements document. I say this because I assume the
>requirements are agreed to (more or less) by the consortium's membership
and,
>consequently, form the scope and intent of the specification. I hope the
>process has enough integrity that the requirements are a valid discussion
>locus.

The intent and scope of XSL are missing from the requirements document. In
the XSL draft itself we have:

"XSL is a language for expressing stylesheets. It consists of two parts:

  1.a language for transforming XML documents, and

  2.an XML vocabulary for specifying formatting semantics.

An XSL stylesheet specifies the presentation of a class of XML documents by
describing how an instance of the class is transformed into an XML document
that uses the formatting vocabulary."

IMVHO mixing the two intents in a single standard is a mistake. There's a
real need for a language which targets just the first part - the interest in
XML demonstrates and drives this need. The second need can obviously benefit
from a transformation language, but is really a separate concern. It isn't
different in principle from needing an XML vocubality for specifying
mathematical formulas, 2D or 3D graphics, invoice data, or any other subject
matter.

>It seems to me that a lot of what is going back and forth here might
>either disappear or be improved in quality and relevance if we communicated
in
>terms of the requirements.

Right. I think we have a basic disagreement between people who use merely
the first part of the intent - XSL as a transformational language - and
people who also care about the other part, the formatting semantics.

[edN]  I wonder how much of this split will still exist in 6 + months when the 
browser bowsers manage to get something working with respect to XML and CSS, 
XSL, and even DSL? (I've mentioned the InDelv alpha/beta code before as and 
example of alternatives -- pretty good support for basic formatting objects a 
la current draft, not so strong but still respectable on the template/select 
side.)

The first group would like a transformational language which is strong
enough to convert XML into whatever target language they need. Being
accessible to the end user is a minor concern.

[edN]  We've just seen some  posts pointing to all sorts of alternatives for 
doing this. If the argument is that it should be done client side as opposed to 
server side, I wonder if this is realistic at this point in the evolution of 
things?

 The second group would like a flexible style sheet language for HTML graphic
designers. Being accessible to such designers is a major concern.

[edN]  I wonder how much of this pent-up and frustrated demand can be placed at 
the doorstep of the rather half-hearted, inconsistent and downright buggy 
implementations of CSS that we have to contend with?

<snip>

[edN]  There are probably other constituencies as well: new technical 
opportunities attract new users/requirements although I don't think the amount 
or degree of change fostered by XML/XSL etc. will be as great as what has 
happened with the advent of HTTP/HTML.

One comment which I found interesting (from Paul Prescod, I think) related to 
what XSL activity really is technical innovation rather than standard setting. 
He feels the effort is doomed to failure. If he is right, the practical, 
cynical side of me tends to agree...another side says, "I hope not."

Perhaps the question is, "Who would you rather have doing your innovation for 
you? An entity trying to live up to rather more altruistic goals such as 
consistency and standardization? Or and entity that is trying to carve up some 
other entity under the aegis of, to me, rather questionable business model 
notions of market share and maintenance? To my mind what has been happening 
over the past 5 + years with respect to HTML and the 'browser guys' has been 
pretty adolescent. At the end of the day, who among them can say there has been 
any gain? There certainly seem to have been losers and that's us who have to 
try make it all work together.

Is there any chance of splitting the XSL draft into two - say, XTL
(eXtendible Transformational Language) and XFL (eXtendible Formatting
Language)?

<snip>

[edN]  In effect, this has been done (if not formally announced), I think. 
There was some back and forth a month or so ago about focusing on the 
transformation side in the short term (whatever that means) and leaving the 
formatting side to later in the process. Realistically, what tools exist do 
this and not much of anything else -- XP/XT, Koala XSL

I wonder if the division isn't rather neatly captured already? On the one hand, 
in the notion of the template matching and relatively straight forward output 
mechanism, i.e., new tag names, additional text, process-children, etc.; on the 
other, with the 'fo' mechanism, i.e., display space management, graphics, text 
formatting, etc.

Are you suggesting that there should be two separate and free standing specs?

Maybe I'm already corrupted but I like the notion of being able to select, 
change/re-order, and show content all in the same place.

What I'm not so convinced is necessary is the ability to run a bunch of 
procedural code as well -- this was the thrust of my initial response to the 
thread. Looking at the XSL requirements document (which admittedly looks a 
little neglected at the moment), the notion of where and when to use scripting 
is pretty clearly articulated. My feeling is that the DOM and intermediate 
tools like the SAXON libraries and even programmable servers, e.g., Jetty from 
Mort Bay Consulting, are a better locale for complex processing requirements; 
certainly for the first go-round of the standard.

Divide & Conquer :-)

[edN]  Yup. I just want to make sure that battle is waged by the hands of the 
right folks.    ...edN





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