xml-dev - Transformation versus annotation

[Paul Prescod <paul@prescod.net>]

"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@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)