[XML-DEV Mailing List Archive Home] [By Thread] [By Date] [Recent Entries] [Reply To This Message] Transformation versus annotation
"Simon St.Laurent" wrote: > > The problem, fundamentally, is that XSL FOs are an element vocabulary, > while CSS properties lived inside attributes or style sheets, without > disrupting the original element names. XSL FOs do not disrupt the "original" element type names. They still exist in the original document that was the source of the transformation. > 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 have DTDs with elements that are processed with rules like: "go to the REF sub-element's HREF attribute, dereference it and check whether the target is a class-name or an instructor-name. If the former, extract the ISO 8869 DATE attribute and format it according to this format rule: '%month% %day%, %year%'. If it is the latter, then dereference each of the "TEACHES" anchors and fetch the ISO 8869 DATE attribute from the element targets. Concatenate them with spaces and output them." 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? If you can write such a language, please do so and let me invest in your company. Something with the simplicity of CSS and the power of XSL is the holy grail of stylesheet inventors. You could build a killer XML editor around it. Adobe would pay millions for it. I, personally, think that is impossible not just practically but even in theory. --- Unworkable solution 1: "Do it server side." * But I want to ship rich semantic data to the client! That's the point of the semantic web! Unworkable solution 2: "Use the DOM" * The DOM could accomplish this task but in doing so it would be essentially a transformation language and thus exhibit all of the flaws that you complain about (generating a second tree with less semantic information). Unworkable solution 3: "Don't do it." * But my clients have terabytes of complex, intricate semantic information that they WANT to make available over the Web (usually for a price). Don't we need that data to build the semantic web? Given that client-side transformations are the least of all possible evils in this case, the question boils down to whether to use the DOM or XSL. We've had that debate already. It boils down to a question of style. (sorry!) -- Paul Prescod - ISOGEN Consulting Engineer speaking for only himself http://itrc.uwaterloo.ca/~papresco [Woody Allen on Hollywood in "Annie Hall"] Annie: "It's so clean down here." Woody: "That's because they don't throw their garbage away. They make it into television shows." 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
|