Subject: RE: About XML to multiple language/multiple outputs From: "Didier PH Martin" <martind@xxxxxxxxxxxxx> Date: Fri, 13 Aug 1999 07:32:48 -0400 |
Hi Frank, Frank said: That is all well and good, but it seems like you are flying into this without any sense of purpose besides making something "new." Fixing inconsistencies and errors in the standard are obviously things one wants to accomplish in a revision. Didier says: OK, I could ask you to spell the word assume but I will simply answer. Read carefully this message... a) yes there is obviously error correction for the next draft b) proposal to modify certain flow objects to add new characteristics to harmonize with online medias and with XSL, CSS extract from a previous message to this list: ----------------------------------------------- As complementary information about CSS, XSL and DSSSL (the XSL section still very incomplete) ref CSS: http://www.netfolder.com/CSS/CSSObjects.htm ref XSL: http://www.netfolder.com/XSL/XslFo.htm ref DSSSL: http://www.netfolder.com/DSSSL/Paragraph.htm So if we take, for instance, the paragraph object, its equivalency in the XSL and CSS worlds is the block object. You'll notice that in the last document (i.e. DSSSL paragraph) a reference is made to the CSS:block and XSL:block objects. This is because these objects are similar. Basically, what James proposed is to add new characteristics to unify the CSS and DSSSL world. Since then, XSL evolved and discussion occurring in the XSL discussion groups and WG added pressure to unify the basic visual models of CSS and XSL. XSL flow objects, however, are still inspired from DSSSL and provide more characteristics than CSS. This may not be the case forever. Actually, the XSL flow object set is more complete than the CSS object set. Some of James suggestions have to be modernized and we need to include the latest knowledge we gained from all these discussions, specifications, implementations (the document is a 1997 document and we are in 1999). However, the proposal has the virtue to add more capabilities in the on-line world and expend some objects, like for instance the scroll and paragraph objects with new characteristics like : background-color background-image etc.... And this is still pertinent to the actual realities. James document is one important base to the document I'll publish about DSSSL-2 possible orientations (but modernized with the knowledge we gained since the last two years). -------------------------------------------- c) also possibility to add new ways to express templates as found in XSL but with DSSSL constructs extract from a previous message to this list: ----------------------------------------------- a) transformation based on templates (suggested by some members of this list as a way to resolve some problems and this do not replace the transformation part of DSSSL-1, just complements it) ------------------------------------------- d) add new functionality like the possibility to do not only document aggregation but also creation of multiple documents form a single input extract from a previous message to this list: ----------------------------------------------- b) multiple input/single output (we get that), single input/multiple output (we do not get that for page oriented rendition). Also, the notion of output document has been left out of DSSSL-1, DSSSL-2 could provide more guidelines (for instance, in one case, a scroll object is associated to a file and in one case the simple-page-sequence is associated to a page context- this kind of ambiguities could be resolved by guidelines or notes added to the specs or by new constructs). -------------------------------------------- Is this more than simply fixing specifications errors? Now, the next item... Frank said: But what are the other things that are up for grabs? For example, are we allowed to break backward compatibility? To what degree? Are we allowed to delete things from the standard? Are extensions acceptable? What must be preserved? Didier says: If some demonstration is made that a previous item in the specification is really bogus (demonstrated by concrete experimentations) this item could be removed. We cannot break backward compatibility. Extensions are obviously acceptable and new items could be added. A specification is a living thing it can evolve with its time. This is why ISO standards like the DSSSL one are renewed after 5 years. These five years are not dominated by emptiness but with experience gained with implementations based on the previous specifications. From this experience, and from needs not fully addressed or badly addressed by the previous specifications, some items could be either deleted (not encouraged) modified (as long as backward compatibility is preserved) or expanded (new objects, features, characteristics (encouraged). The transformation part of the DSSSL-1 specifications was never implemented. We cannot say that this part is not useful nor say that this does not work properly. Therefore, even if it where never implemented, it could (if Brandon make it - Brandon, we need you there :-). So, this part being not demonstrated as bogus should be kept. Some may not like the syntax being scheme based, but this cannot be demonstrated also that this syntax is bogus. This is also kept. So, the actual spec could be kept, and bugs in the text corrected. However, we can improve by adding new features. or expanding the already existing features. Some flow objects needs some additional characteristics to offer more functionality extract from a previous message to this list: ----------------------------------------------- However, the proposal has the virtue to add more capabilities in the on-line world and expend some objects, like for instance the scroll and paragraph objects with new characteristics like : background-color background-image etc.... ---------------------------------------------- A new section based on templates could be added to the specifications. The section could (I do not say will) be named "template-specification" and itself contains a declarations element and a "template-specification-body" (there is a high probability that the declarations are to be superfluous and then only the element "template-specification" would be needed). As an example of a template specification: <template-specification> <HTML> <TITLE><dsssl:query (title:child(data))></TITLE> </HTML> </template-specification> Note: i do not say that the construct would necessarily as stated in the template. This is provided only as an example not as a final direction. This new section would require from us to improve the query-expression. James made the suggestion of a query language (at that time it was not so clear, today we would say it was the first step toward XPath) for element-match. Ken Holman, made the suggestion of a Query language based on a simplified query language able to acces any element in the grove. So here, an other area of improvement. We may keep the actual query-expression-language also shared by Hytime (v 2.0) but could add new simplified constructs allowing not only rule based (push model) but also templates as above (pull model). This could leads to simplified implementation of rules like the rule "query". Also a flow object could be created as a template and referred with a procedure within a rule. <template-specification> <dsssl:flow-object id="div"> <DIV style=(characteristic("style"))> hello the people of this world </DIV> </template-specification> <style-specification> ..... (element item (make div style: "etc....") ) ) </style-specification> Note: the example above is stated only as a suggestion or as a first step for further reflection not as a final direction. The first task as stated previously is to first sort this, collect the people's needs: unfulfilled needs and needs fulfilled with high costs. See if some of the previously stated solution may provide an adequate solution to these problems and then prepare a first draft. We are now at the probing stage. It is open to suggestions and comments from people. However comments like: it seems like you are flying into this "without any sense of purpose besides making something "new." Could make me regret having chosen an open dialog with the DSSSL community. I could have chosen to prepare the draft behind closed doors without any previous consultation from the user community. However, what is reassuring is that a lot of people instead feed the process by expressing unfulfilled needs and making constructive comments and suggestions to the table. I hope Frank, that you'll go from this kind of comment to useful contribution by helping us compose a better draft. Then, we'll work hard to carry this draft to a formal specification and then bring this latter toward acceptance from the ISO community. regards Didier PH Martin mailto:martind@xxxxxxxxxxxxx http://www.netfolder.com DSSSList info and archive: http://www.mulberrytech.com/dsssl/dssslist
Current Thread |
---|
|
<- Previous | Index | Next -> |
---|---|---|
RE: About XML to multiple language/, Frank A. Christoph | Thread | Re: About XML to multiple language/, Matthias Clasen |
Re: Pass parameter to Jade?, Kai Großjohann | Date | Per-language processing (was: Pass , Toby Speight |
Month |