Subject: XSL Requirements (was: Microsoft extensions to XSL) From: "Oren Ben-Kiki" <oren@xxxxxxxxxxxxx> Date: Sun, 15 Nov 1998 13:11:35 +0200 |
Ed Nixon <ed.nixon@xxxxxxxxxxxxxxxxx> wrote: >I think this might be the point at which we could sit back and take a look >(again?) at the requirements document. I say this because I assume the >requirements are agreed to (more or less) by the consortium's membership and, >consequently, form the scope and intent of the specification. I hope the >process has enough integrity that the requirements are a valid discussion >locus. The intent and scope of XSL are missing from the requirements document. In the XSL draft itself we have: "XSL is a language for expressing stylesheets. It consists of two parts: 1.a language for transforming XML documents, and 2.an XML vocabulary for specifying formatting semantics. An XSL stylesheet specifies the presentation of a class of XML documents by describing how an instance of the class is transformed into an XML document that uses the formatting vocabulary." IMVHO mixing the two intents in a single standard is a mistake. There's a real need for a language which targets just the first part - the interest in XML demonstrates and drives this need. The second need can obviously benefit from a transformation language, but is really a separate concern. It isn't different in principle from needing an XML vocubality for specifying mathematical formulas, 2D or 3D graphics, invoice data, or any other subject matter. >It seems to me that a lot of what is going back and forth here might >either disappear or be improved in quality and relevance if we communicated in >terms of the requirements. Right. I think we have a basic disagreement between people who use merely the first part of the intent - XSL as a transformational language - and people who also care about the other part, the formatting semantics. The first group would like a transformational language which is strong enough to convert XML into whatever target language they need. Being accessible to the end user is a minor concern. The formatting semantics are irrelevant (unless you are lucky and they are part of the target language). The XSL sheet is used to as part of some conversion process, say taking data from a database and presenting it as HTML. The second group would like a flexible style sheet language for HTML graphic designers. Being accessible to such designers is a major concern. The transformational powers are secondary as long as common tasks can be performed (and these don't require much). The XSL sheet is embedded inside an HTML document or maybe is used to generate HTML fragments. Is there any chance of splitting the XSL draft into two - say, XTL (eXtendible Transformational Language) and XFL (eXtendible Formatting Language)? The XFL people would be able to use a subset of XTL suitable for graphic designers (say, ignoring scripting, modes and so on), while the XTL would ignore XFL (since they are translating to some other target language). Each group would be able to focus on its own needs without bothering the other. Divide & Conquer :-) Oren Ben-Kiki XSL-List info and archive: http://www.mulberrytech.com/xsl/xsl-list
Current Thread |
---|
|
<- Previous | Index | Next -> |
---|---|---|
Re: XQL + XSL = Better (kinda like , Mark D. Anderson | Thread | RE: XSL Requirements (was: Microsof, Didier PH Martin |
Re: XQL + XSL = Better (kinda like , Mark D. Anderson | Date | RE: XSL Requirements (was: Microsof, Didier PH Martin |
Month |