Re: W3C-transformation language petition

[Guy_Murphy@xxxxxxxxxx]

Hi.

You insist on still refering to XSL as having a transformative part and a
styling part, suggesting that the transformation doesn't belong with
styling.

The FOs are formatting not styling, so XSL has transformation and
formatting.

I continue to maintian that styling *is* transformation and formatting, and
that the two parts are therefore requesite for a styling language

[QUOTE]
"XSL has this dual nature because of the organization of its specification.
The transformation part of the language is separate from the part that is
specific to stylesheet application."
[END QUOTE]

I believe that the above to be an extremely poor representation of XSL. The
FOs are *not* the stylesheet part, they are merely formatting. Equally the
transformative part is not the stylesheet language, it is merely the
transformative part. Both together make a style language.

You seem to be using the likes of CSS as the yardstick for what a style
language is. I'd suggest that such is a poor measurment as IMHO CSS is
*not* a style language but a formatting language.

I appreciate that there are vendors that are intending to role out XSL
parsers, and are concerned about the markrting. Personally I don't see the
problem. The vendor of said parser can still claim 100% XSL conformance as
the parser can indeed output FOs, it's the user agents problem if it
supports FOs. 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?

As for your two points...

[QUOTE]
"1. It should be possible to implement only the transformation language and
have the implementation conform to some W3C named, formally-defined
language.
2. It must not be possible to create an implementation of a W3C-defined
language called XSL unless the implementation supports formatting objects."
[END QUOTE]

Isogens, or Activateds or 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 say...

[QUOTE]
This muddy definition of "XSL implementation" is dangerous. Even when the
XSL specification is complete, a browser vendor could conceivably
implement only the transformational part of XSL. When challenged, they
could point to these other half-implementations as evidence that this was
a valid choice to make.
[END QUOTE]

...but I would say that a browser manufacturer could not claim that their
user agent is 100% XSL conformant as it cannot render FOs. I don't believe
it valid to compare a user agent with a simple parser.

Its a bit like having a parser that can process HTML and being concerned
that because the parser doesn't render HTML that we're going to have a hard
time marketing it becasue it's not a user agent.

And the stuff about conformance testing I believe is a red herring. The
transformative and formatting parts of XSL could be tested independantly
regardless of the language being a whole or in two parts.

I'm sorry Paul, I still see your lobbying as essentially a marketing
exercise, and don't see how it will benefit XSL as a styling language,
although I admit that what you suggest might make life easier for the
marketeer I still stick to the line that it's a poor reason to cripple XSLs
prospects as a complete XML styling solution.
I apollogise if it appears that I'm hounding you on this issue Paul, it's
just I belive in the vital importance of XSL being a whole styling
solution, both transformative and formatting, and that the whole solution
be actualised in the market place. I belive that the splitting of XSL will
further schisms, not disolve them. A large part of the driving force behind
XML/XSL has been the experience of such schisms and their damage to
development. With XML we have a whole solution to mark-up, and hopefuly
with XSL we will have a whole solution to styling.

I further believe that if we weaken the unified nature of XSL as a styling
language we let Microsoft and Netscape off the hook, and all we are ever
likely to see is XML and CSS for formatting.

For the CSS advocate this might be an attractive prospect, and they need
not knock the aspirations of the XSL advocate as they already have XML/CSS.
For those however, that are hoping that we might one day see the Web used
as a rich media delivery and navigation mechanism, irrespective of voice,
print or screen utilisation, CSS cannot be seen to be up to the job for XML
styling. We must therefore push for actualisation of a complete XSL
solution for XML styling.

Cheers
     Guy.



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