[XML-DEV Mailing List Archive Home] [By Thread] [By Date] [Recent Entries] [Reply To This Message] Re: Transformation versus annotation
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@i... 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@i... the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@i... the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@i...)
|
PURCHASE STYLUS STUDIO ONLINE TODAY!Purchasing Stylus Studio from our online shop is Easy, Secure and Value Priced! Download The World's Best XML IDE!Accelerate XML development with our award-winning XML IDE - Download a free trial today! Subscribe in XML format
|