Subject: RE: Formatting Objects considered harmful From: "Reynolds, Gregg" <greynolds@xxxxxxxxxxxxxx> Date: Fri, 23 Apr 1999 17:00:00 -0500 |
In response to the "FO Considered Harmful" debate: The emphasis on "semantically rich" markup seems misplaced to me. There is always some form of mediation. The only way to get at the "semantics" of data is by going through some intermediary: a query language. The relation between such a language and a presentation language is undefined; such a language itself presents a particular view of the "original" data. After all, a tree query language can be used to query a relational table, just as SQL can be used to present a relational image of (many) tree structures. To see this its enough to consider the experience of the reader of a paper book who wants more information about some topic in the book. Such a reader has many means of seeking such information, and many ways of asking questions. The original form in which the "data content" of the book is stored is irrelevant, at least to the inquirer. It has been transformed, in all likelihood. This is obviously the case with the web. Its also the case with report writers that query relational data bases and present the results on a screen. So whether or not the data format used to convey presentational semantics to a browser contains "semantics" is not really the central issue. Or rather, you have to make a lot of assumptions about the world to think it essential. It reflects a data-centered view of the world, but in my view at least a function-centered view is more appropriate. Its especially weird considering that the whole point of XSL in contrast to CSS is to support the transformation of XML data. If one transformation is possible, so are many, giving us many data representations, just as a sytle language gives us many presentational representations. Which data representation do you want to query today? Which query language do you want to use today? It seems entirely likely to me that we will see lots of XML data structures whose design is driven by data modeling considerations, and that stylesheet designers will transform such structures into other XML structures whose design is driven by presentational semantics, regardless of the style language used. Tracability from presentational abstraction (e.g., this bolded heading rectangle) to original data structure through n transformations should be treated as a distinct topic. To put it another way: Hakon's paper addresses valid and important general issues, but unfortunately it reflects the XSL/CSS holy wars rather than a cool analysis of the underlying issues. Finally, here's an alternative model: lambda x.(presentational-design-notation-expression x) xml-data ==> pixels (=presentational form) How the xml-data gets to be that way is irrelevant from the perspective of the presentation designer. No reason it even needs to be xml, only structured. If the transformed representation retains the semantics of the "original" data representation, great, the job of the query software is easier. If it has gone through 37 transformations, so be it, but then if you want to query back to the Urdata? Not my job. Let the query language designers provide for traceability, and the xml transformation programmers retain semantics if they wish; the style/formatting/composition language designer can only only provide for traceability back one step to the xml-data. From there on, its somebody else's problem. But thats the way it should be - divide and conquer. The real problem with formatting objects (and similar abstractions) is not that they hide semantics, but that they reflect a data-centric design philosophy (style attached to tree nodes!?!?) and they model the wrong thing (one implementational view of the formatting process). Its not so much that they're harmful but that they're completely unnecessary. The alternative is a reader-centered design philosophy used to model the things readers use: documents, not the process of formatting documents, and certainly not one implementation of a formatting process. Tracability from presentational-forms back to the xml-data is implementation-defined - you want more of it, you pays. All in all FOs are better than nothing for now. It'll probably at least another 10 years of experimentation anyway before the world begins to settle on solutions to these issues. Cheers, gregg's personal opinion service (Gregg Reynolds, Datalogics) XSL-List info and archive: http://www.mulberrytech.com/xsl/xsl-list
Current Thread |
---|
|
<- Previous | Index | Next -> |
---|---|---|
Re: Formatting Objects considered h, Guy_Murphy | Thread | Re: Formatting Objects considered h, Guy_Murphy |
ANNOUNCE: SAXON 4.2 - An XSL Compil, Kay Michael | Date | RE: Newbie question, Kay Michael |
Month |