xml-dev - Re: Transformation versus annotation

["Simon St.Laurent" <simonstl@simonstl.com>]

At 06:28 AM 6/16/99 -0400, Paul Prescod wrote:
>XSL FOs do not disrupt the "original" element type names. They still exist
>in the original document that was the source of the transformation. 

The result, however, looks nothing like the original.

>> See above.  Transformations to an endpoint that still had as much semantics
>> as the original - formatting properties represented as attributes rather
>> than elements - might have avoided lots of the 'considered harmful' issues
>> that you want to ignore.  I think inclusion and sequence are the only large
>> problems such an approach presents, and I don't think they're insoluble.
>
>They are insoluable. The whole point of transformations: whether XSLT or
>DOM is that they are *arbitrarily sophisticated*. That means that I can
>have a very loose binding between markup and presentation. That means that
>I can invest in my expensive information assets without worrying about the
>presentational technologies of the day.

I'm not convinced that arbitrarily sophisticated is required by the vast
majority of cases - and I'm definitely not convinced that inclusion and
sequence in particular are insoluble.  We already have a tool -
DOM+Scripting - that is capable of providing arbitrarily sophisticated
transformations, and document composition (rather than transformation per
se) addresses many needs that are remarkably complex while allowing
developers to use the frameworks of their choice.

>Do you propose that after 15 years of failure we now have the ability to
>make style languages in the annotation model that can solve the many
>common (common!) problems of this sort?

What follows is a remarkably negative message. Your underestimation of the
capabilities of CSS (expressed in a previous message) is severe, your
willingness to declare problems insoluble is remarkable.  Perhaps it's just
that you've admitted that:

>Nobody solved the FOs considered harmful problems because they are
>*insoluable*.

and you now have to declare a wide variety of alternatives insoluble.
Annotation by itself may not be up to every task, but annotation with a
minimal level of transformation (starting even with :before and :after,
which we already have) seems capable of addressing the vast majority of
tasks.  It's not a matter of reinventing everything; it's more a matter of
finding solvable issues and fixing them.

Simon St.Laurent
XML: A Primer / Building XML Applications
Inside XML DTDs: Scientific and Technical (July)
Sharing Bandwidth / Cookies
http://www.simonstl.com

xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk
Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ and on CD-ROM/ISBN 981-02-3594-1
To (un)subscribe, mailto:majordomo@ic.ac.uk the following message;
(un)subscribe xml-dev
To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message;
subscribe xml-dev-digest
List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk)