(make sure to reload if you have been here before)
Name: Paul Prescod
Opinion: Create a transformation language
Comment: Not surprisingly, I agree with Paul!
Associated URL: http://www.prescod.net/xsl/petition/
Name: Nick Manson
Opinion: Create a transformation language
Comment: I am in agreement so long as: a) splitting the current specification does not significantly delay the transformation portion of the XSL recommendation. b) the FO specification strengthens sufficiently to allow browsers to navigate using it alone. By this I mean that sufficient grammar is added to the FO specification to allow all kinds of links proposed by XLink.
Name: Incze Lajos
Opinion: Create a transformation language
Comment: Fully agree. As I see, it is really a hardly disputed common sense in the developer community what you have put up. Incze
Name: Liora Alschuler
Opinion: Create a transformation language
Comment: I'd like to see this happen. I'm not sure why Paul has taken this course to make his opinion known, but the recommended action seems quite reasonable.
Name: Clark Evans
Opinion: Create a transformation language
Comment: For my bookkeeping application, behind the scenes I need to transform one type of entry into another type of entry based upon business processing rules. Thus, I have a deep interest in having a transformation language, but have no use in the back end for stylistic output. Thank you! Clark Evans
Name: Takuki Kamiya
Opinion: Create a transformation language
Comment: Transformation language can stand on its own without being coupled with stylesheet capability. Moreover, by de-coupling style vocabulary from transformation language, transformation language could become more widely applied to non-styling applications such as XML-object mapping, XML-Schema mapping and so on.
Associated URL: http://www.fujitsu.co.jp/
Name: Toivo Lainevool
Opinion: Create a transformation language
Comment: It is clear from current use of XSL that the transformational part of it is useful on its own. Having a separate spec for it makes sense.
Name: Don Park
Opinion: Create a transformation language
Comment: XTL sounds good.
Name: Marcus Carr
Opinion: Create a transformation language
Comment: I have never felt that transformation and styling were just different aspects of the same process - if they were, they would probably be performed concurrently. The fact that they can't be, to me, is the biggest indicator that they are indeed different processes and should be goverened by separate specifications. Additionally, it is becoming apparent that nobody intends to provide XSL support for the specification as it stands, so the label of "XSL support" on an application is going to be meaningless. The idea of fragmenting the XML initiative is what has given it enough steam to get past SGML and keep rolling. I see no reason to not extend that same paradigm to separating the transformation and stylistic aspects of XSL.
Name: Mike Daconta
Opinion: Create a transformation language
Comment: Good job Paul. Your observation of this important fact will increase the modularity and layered approach of implementations. This greater flexibility is a win for developers. I hope the W3C is listening. - Mike Daconta
Associated URL: www.gosynergy.com
Name: Jim Amsden
Opinion: Create a transformation language
Comment: Transformations will be required to merge documents from different sources into a new document that has some new purpose, particularly for data exchange in e-business applications. This will be especially important in transforming older documents into proposed standard document languages as these evolve.
Name: Jason Diamond
Opinion: Create a transformation language
Comment: I am in complete agreement with Paul. Without a seperate transformation language, vendors claiming XSL compliance but only implementing the transromation part (like Microsoft) will only undermine all of the hard work put into the specification by the W3C, confuse users, and berate content providers.
Name: Anthony B. Coates
Opinion: Create a transformation language
Comment: It's such an obvious thing to do, it would be a pity not to look ahead a bit and anticipate the need.
Name: Linda van den Brink
Opinion: Do not create a transformation language
Comment: - People will want to use both transformation and formatting together on XML documents (as is also done with DSSSL). If you separate these two parts of XSL, then people will need to mix two languages instead of being able to use one for a possibly (but not necessaril) mixed purpose. - If the formatting part is separated from the transformation part, then we could probably throw it away all together and use CSS instead. I read arguments from CSS users all the time demanding functionality that already exists in XSL without them knowing it. CSS will then probably be expanded to cover the current formatting part of XSL. - As soon as the XSL spec is a recommendation, why could the W3C not forbid implementations of XSL that cover only half of the spec to claim XSL support?
Name: Andy Dent
Opinion: Create a transformation language
Comment: I believe it will be in the interest of vendors providing XSL (transformation) solutions and end-users to have a more focussed specification, so debate over formatting languages doesn't hinder XSL being polished. I have profound doubts about the viability of the FO side of XSL on technical, usability and political grounds.
Name: Chris Angus
Opinion: Create a transformation language
Comment: I am strongly in favour of the proposal. I believe that there are two different sets of requirements, although clearly some user's needs will span both. Divide and conquer?
Name: Bob DuCharme
Opinion: Create a transformation language
Comment: XML's rising popularity in its first year, even as we waited for big-name browsers that let us format arbitrary element types, showed that the non-SGML world saw much more potential in XML than just "HTML with your own tag names." Applications that manipulate the data without caring about its actual appearance in any media have become a huge part of XML, and a clean break between defining these needs and those of pure publishing apps will make for cleaner architectures in both application categories.
Associated URL: http://www.snee.com/bob
Name: Frank Richards
Opinion: Create a transformation language
Comment: Very good idea. There is a large class of applications that just want the transformation language. I think splitting the spec (or subsuming the formatting part into CSS) will also speed the development of formatting tools. XTransformL and CSS2 would be a useful combination, but there seems to be no complete CSS2 implementation and IMO effort is being diverted from rendering to transform by the current spec structure. Right now we need rendering.
Name: Paul Tyson
Opinion: Create a transformation language
Comment: Mainly because it will make plainer what it means to use structured information standards. The essence of transformation is to select a thing and do something with it: a transformation language must express notions of selection and action. The essence of applying style is to render something as specified: a style language must express notions of identification and description. The two problem domains, at least in the XML world, are sufficiently different to warrant separate specifications. For those familiar with the DSSSL specification, the WD-19981216 incarnation of XSL makes sense. DSSSL managed to specify a beautifully simple, uniform, and robust syntax for querying (selecting), transforming, and styling. Unfortunately this elegance cannot easily be reformulated in the keep-it-simple-and-make-it-work-quick-now XML world (especially if you have to satisfy the for-God's-sake-make-it-XML-syntax folks). So, a curmudgeonly "yes" to Paul's motion.
Name: Jeff Bellegarde
Opinion: Create a transformation language
Comment: I would like to have an XML->XML transformation language. A general purpose transformation language could be used to solve a much larget set of problems then the current XSL while still being able to do style. Once we have transformation tool, defining a formatting language to transform to is relatively simple. Conversely, a complete style language doesn't solve the transformation problem at all.
Name: John Cowan
Opinion: Create a transformation language
Comment: I agree with the Prescod petition entirely. A formatting language does not require a transformation language, and a transformation language does not require a formatting language. There are many applications for which one is relevant but not the other. Before the current XSL draft had emerged, I was in process of designing a transformation language which had nothing to do with formatting, based on the GNU m4 processor adapted to XML. I have now suspended that effort in hopes that a W3C standard transformation language will emerge from the XSL process.
Name: Sara Mitchell
Opinion: Create a transformation language
Comment: I agree, most especially because I also think that it is likely that browser vendors will only implement the transformation part of XSL and not support the formatting object piece. The transformation part is being implemented now because it can be and because the browsers don't yet support the FO piece. The only way, currently, to display XML is to transform it to HTML. Separate standards would make the browser vendors accountable and would make it clearer to the "general" public and the "implementing" public as well.
Name: Keith Visco
Opinion: Create a transformation language
Comment: Paul, I am in general agreement with your efforts here. I do disagree with paragraphs six and seven. I don't think that citing current implementations is appropriate for justification of any future implementations. Since, of course, any works referencing the XSL WD must be considered "In progress" it would be inappropriate for a browser vendor to cite "In progress" works as justification. However it certainly illustrates the usability of the Tree Construction independently from Formatting as well as the opposite. I am associating a URL to a comment I posted to the XSL news group the last time you brought this topic up. XSL:P is only a half implementation currently and will eventually conform to whatever lies ahead in future Working Drafts, including Formatting Objects. Other than those two paragraphs...I agree. --Keith XSL:P (http://www.clc-marketing.com/xslp)
Associated URL: http://www.mulberrytech.com/xsl/xsl-list/archive/msg02516.html
Name: Jerome McDonough
Opinion: Create a transformation language
Comment: I agree with both the premise that many people require the ability to engage in transformation without formatting, and that separating the transformation language from the formatting/style sheet aspects of XSL will work to the benefit of both those focused purely on transformation processing and those working on rendering/display. Frankly, while recognizing the inter-relationships between transformation and rendering, I think that the conflation of these two in DSSSL was one of the reasons that DSSSL took so long to see any serious use.
Name: Thomas Gafford
Opinion: Create a transformation language
Name: Scott S. Lawton
Opinion: Create a transformation language
Comment: 1. A transformation language is useful independent of formatting. Think e-commerce or interapplication communication or any other sort of data exchange. 2. There are many ways to describe a formatted document. The two problems are distinct enough that they are best solved separately.
Associated URL: http://www.mulberrytech.com/xsl/xsl-list/archive/msg01231.html
Name: Randy MacDonald
Opinion: Do not create a transformation language
Comment: Could you lighten up on the large font text? I would like to save paper when I print from MSIE, and setting the View Font Smallest only gets me normal type.
Name: Renee Verdegaal
Opinion: Create a transformation language
Associated URL: www.etcl.nl
Name: Michael Korolkov
Opinion: Create a transformation language
Comment: I see a lot of applications for a general-purpose XML transformation language. It could become a very important tool for creation and manipulation of XML data. But to become such a tool it must be much more powerfull and have a much reacher set of features than its current incarnation within XSL. And since stylesheet language does not encourage enrichment of transformation language, this transformation language longs to be made independent from style.
Name: Noel Cross
Opinion: Create a transformation language
Name: Alex Jacobson
Opinion: Create a transformation language
Comment: Transformational languages are very similar to functional programming languages. My suggestion is that pure-lazy functional programming languages, like <a href=http://www.haskell.org>Haskell</a>, are ideally suited to this application because they focus on the sophisticated things you can do without state (changing variable values).
Associated URL: www.haskell.org
Name: Michael Kay
Opinion: Create a transformation language
Comment: Yes, I agree. I had assumed that the way the XSL spec is written, it is pretty obvious that the editors fully understand that the two parts are technically independent. I'd like to see XTL separated not only because it is useful on its own, but because it would allow it to develop greater power outside the "styling" context, for example the ability to take multiple inputs and produce multiple outputs, and some kind of ability for multi-stage processing (treating the output of one stage as the input to the next).
Name: David Baron
Opinion: Create a transformation language
Comment: For purposes of measuring conformance, I agree that it is very important to have separate specs for separate things. It would be very confusing to have browsers that "support" XSL when one supports transformations and the other supports the FO. I would think it would be best at the least to define conformance for each half of XSL rather than the whole thing.
Name: Fred L. Drake, Jr.
Opinion: Create a transformation language
Comment: I would find a transformation language very applicable to the document conversions with which I find myself involved. I modular transformation language would be very welcome. There should be a mechanism for extensions to be requested or required by transformations, possibly in a similar manner to the DSSSL extensions offered in Jade.
Name: Dean S Jones
Opinion: Create a transformation language
Name: Paul Tihansky
Opinion: Create a transformation language
Comment: If the style language and the tranformation language are separated, then we don't have to wait for both languages to be mature before finalizing the recommendation. That might help us get tools sooner.
Name: Kevin Russell
Opinion: Create a transformation language
Name: David Wright
Opinion: Create a transformation language
Comment: I agree with Alex Jacobsen that functional languages seem ideally suited as they make it very easy to implement tree transformations. Haskell seems a stable and mature starting point.
Name: DigiGod
Opinion: Create a transformation language
Comment: I think that XTL would be of greater use to all if seperated from its current house XSL.
Name: Malcolm Wallace
Opinion: Create a transformation language
Comment: First a note about terminology: would I be right in suggesting that XSL currently covers both a full transformation *language*, and a style formatting *vocabulary* (FO)? It seems to me that it would be extremely easy to split these two apart with no damage to either component. Secondly, another plug for Haskell as an alternative transformation framework. There are some draft ideas for generic XML transformation based on combinator programming in Haskell at the URL below. I'm also working on linking DTDs to Haskell's static type system: this would bring in something new - the possibility of validating complete transformation scripts, not just documents.
Associated URL: http://www.cs.york.ac.uk/fp/XmlLib/
Name: Bill Ayers
Opinion: Create a transformation language
Comment: There is a requirement for a transformation language for problems which are outside the scope of styling and FO. The transformation part of XSL perfectly satisfies that requirement. Please can we borrow it? - we promise not to break it!
Name: Steve Robertson
Opinion: Do not create a transformation language
Comment: I would not like to see the transformation and style formatting seperated from XSL. It doesn't bother me if there are two specifications but I object to the possibility that we will need two processors. Is this what most people want? - I don't think so! XSL is a great transformation language for XML and the styling will be a real bonus. Although in practice it may be best to keep the styling in a seperate, but included file, these should be combined by a single processor. Seperate them and XSL becomes less efficient, less applyable, and less successful. Surely nobody wants that! When the XSL specification is complete I will expect a valid XSL engine to support the full specification. If only the transformation part of the XSL specification is implemented, people will naturally embed style in any transformations to HTML. That will discourage its adoption on the web and it defeats some of the point of XSL. Obviously many of the people submitting their remarks do not appreciate the application of DSSL to SGML. Think again! please.
Name: Michael Fischer
Opinion: Create a transformation language
Comment: I most strongly concur with the need to create an XSL like tranformation language with its own extensions that meets needs that differ from from formatting. There is, of course, no reason why both could not be included in a single framework, but there should be a different specification for each, and they should well diverge, since transformations are not of universal interest, but have specific needs. I use XSL almost entirely for transformation (with a bit of rendering into HTML). I have been adding my own extensions to meet the needs of several research projects, on the assumption that most other people were less concerned with this issue. I have been keeping to the style of XML, so that I can use common parsers to validate results, but add things like associative arrays and evaluating simple expressions by adding virtual extensions/templates to the current xsl document tree, while keeping it well formed. I would thus like to support and be actively involved in any such initiative. Michael Fischer Director Centre for Social Anthropology and Computing Univerity of Kent at Canterbury
Associated URL: http://lucy.ukc.ac.uk
Name: Stefano Bovone
Opinion: Do not create a transformation language
Comment: I think that the XSL Working Draft shouldn't be divided. I think is necessary a join developing both of the transformation rules and the Formatting Objects section. It's my personal opinion that CSS of Level 1 and 2 are to poor for printing: it's necessary something to do a surther progress. Formatting Objects should have to become something which can really be an available way to see something printed or viewed. CSS has a serious problem: it is thought for Internet document hence for unpaged document. XML, XSL, for me, must see Internet only how a possible field for applications, but there are several other fields out the net. We may think,for example, at the work of catalogue documents and to the elaborations necessary for printing. I know, you can tell me there are SGML and DSSSL: too complex, to difficult to use them. XML and XSL could be the solution. I think to divide FO from XSL WD would be the end of the FO themselves. I hope, instead, to have a WD with more details and certainies as soon as possible, so me, my factory and many other factories may produce experimental software that support FO beginning from a fairly firm base. There aren't only Netscape, Microsoft, ..... Best regards. _________________________ Stefano Bovone Elsag S.p.A. Via Puccini 2 (GE) 16105 Sestri Ponente (GE) Italy http://www.elsag.it/ email: Stefano.Bovone@elsag.it
Name: Carlos E. Perez
Opinion: Create a transformation language
Name: Rick Ross
Opinion: Create a transformation language
Comment: The adoption of this critical technology will be accelerated by the separation of the transformation and formatting objects sections. I strongly favor the separation.
Associated URL: http://www.activated.com/axsl.html
Name: Ken Sall
Opinion: Create a transformation language
Comment: Many people not on the XSL-List already think only "style" when they hear the term XSL. They associate this with what they know: CSS. The fact that the XSL Working Draft addresses 2 types of functionality, one having nothing directly to do with style, is indeed confusing. Since the transformation aspect of XSL has significant utility of its own, I agree that it would be highly desirable to specify a transformation language and not get into the mess of having partial XSL implementations.
Name: Andrew Redhead
Opinion: Create a transformation language
Comment: I am certain that XML requires a transformation language and a styling language. I am also certain that the styling language should build on the transformation language. I can see no good reason for wrapping the transformation language and the styling language into the same specification.
Associated URL: www.thomsonconsulting.com
Name: Rob McDougall
Opinion: Create a transformation language
Comment: As Paul has eloquently argued above, a transformation facility is something that will generally be required by *any* application that wishes to process arbitrary (i.e. non-specified) XML. Styling is just an example one such application, but there are many others. The transformation language should be seperated from the styling vocabulary so that it may be re-used in other XML processing applications.
Name: David RR Webber
Opinion: Create a transformation language
Comment: Paul, My take on this is very different. Yes, we do need a transformational language for electronic commerce, but it is NOT the XSL approach. This is not to say that XSL will not be used, it is and will be effective. However, it is also not a silver bullet for enabling eCommerce/eBusiness. Therefore I have less of a problem with the current focus of XSL - namely form based HTML transformations and rendering. Let me explain this from the business focus. XSL is a incredibly adaptable and controllable tool. It requires some level of programming expertise to use. The complexity on a scale of 10 can vary from 5 up to 10. What is needed for broad electronic commerce is a transformation tool where the simplicity ranges from 2 to 6! In other words, every time you transform business data it costs you money. The more complex it is to do, the more money it costs, and most key, the more money it costs to maintain. Also, the harder the tool is to learn, the fewer people know how to use it, and the more it costs to hire them. Therefore, businesses will veer towards the simpler lower cost option. I shall be releasing next month early details and implementation of the XCHG syntax for business data exchanges. Strikes against: Groan - not another Xlanguage, please! When will this be built-in to my browser? Who is going to adopt this anyway? This has been tried before, it doesn't work that easy. We're already doing that with Perl, we don't need this. My database already does XML import, what does this add? You're smoking some heavy shit, go away! Strikes for: Great - the data people can use XCHG for 90% of their needs. XCHG and XSL are highly complimentary, use XCHG for the grunt work and legacy EDI, use XSL to fine tune and do custom rendering, and neat forms stuff and stuff off the beaten path. Heck - XCHG is so simple, even my mother can do this. Why didn't we think of this before? The XCHG engine is tailored for descrete transformations, therefore it 'knows' how to do these, we merely have to guide it. This removes a great deal of the programming that is otherwise needed. EDI was limited because we could not share a common information control syntax. XCHG fits and makes open interchanges possible for end users. Vendors can adapt their existing products to support XCHG without major grief. They don't necessarily have to rely on someone elses XSL implementation. This allows us to separate the problem into well defined layers. The XCHG layer covers datacentric issues, the XSL the rendering and form layers. This helps both keep simpler, and also makes it easy to explain to people when to use XSL and when to use XCHG. XCHG and XSL share common syntax in areas such as DATE() and other common methods, thereby reducing the learning curve for both. It's a simple Java component, so you can extend browsers easily by just downloading it, or even run it off a server and pipe data and templates in and out. OK, I have to get back to work, but at this point I wanted to establish a point of note. Obviously all bets will be off until you actually see XCHG. The proof of the pudding is in the eating! Thanks, David Webber.
Associated URL: www.gnosis-inc.com
Name: Bomans
Opinion: Create a transformation language
Comment: Eurotransplant created a prototype of a transformation language which currently (nov. 1999) is being tested for user acceptance. The transformation language consists of a dozen specification tables which explain how a foreign database is transformed to the Eurotransplant database. (Of course, for the Eurotransplant database you can read any database; the fact that the specification is in a tabular language could easily be remedied, for example, by converting the specification tables to a special kind of XML format.) The transformation carries out the following steps: 1. recognize the incoming columns from the headers on top of the columns (so, any amount of columns may be sent in any order.) 2. restructure the database; for example, information packed into 3 tables (as repeating groups, flattened as buckets etc.) is normalized to 9 tables, depending on the application. 3. reinterpret the context i.e. 3a. translate codes to and fro (note: if two foreign codes A and B map to a single code X, then X needs to be translated back to a unique foreign code, say A.) 3b. convert units of measure, e.g. milliter to liter 3c. transform data formats, e.g. 14/12/99 to 14-12-1999. On the basis of these tables, Oracle source code is automatically generated and executed to actually carry out the transformation. This language should be extended from a transformation language to a transaction processing language. In conclusion, specification tables generically model data transformation. The problem I envisage is that Eurotransplant must spend quite some effort to model foreign databases with this package and to maintain the package. Therefore I would like to contact an organization which can maintain this database exchange (DBX) module, install it, instruct users, and so on. Arnold Bomans, programmer Eurotransplant 8 nov. 1999
Name: Bomans
Opinion: Create a transformation language
Comment: As my email was not displayed as a separate field in my previous petition, here it is as a comment: abomans@eurotransplant.nl
Name: gjkkk
Opinion: Create a transformation language
Comment: hjklhjkl
Associated URL: hjkl
Back to petition.