Subject: [xsl] interoperable use of xml technologies From: "cutlass" <cutlass@xxxxxxxxxxx> Date: Mon, 8 Oct 2001 11:02:48 +0100 |
hello all, i want to highlight an interoperability issue, which may or may not be an XSLT issue ( depending on your viewpoint, many apologies ), at least i find that one doesnt use XSLT in a vacuum but always in tandem with other xml technologies (<corny> i see XSLT as the bass player in the typical 4 man r+b line-up; its very hard to just play a bass all by itself</corny> ). after combining the use of XFORMS, SVG and XHTML into one application, and using XSLT to be the 'glue' that informs ( or generates ) each vocabulary; i have rediscovered some interoperability 'knots'. a few scenarios; 1) i want to use xhtml in SVG 2) i want to have an SVG expression of an XForms definition 3) i want to use XHTML, SVG and XForms all in one page, and use XSLT to either generate or inform all elements. A discussion that is occuring on the SVG list about xhtml support for display within a<foreignObject>, caused me some confusion. Should i expect XHTML support to be dealt with the HTML parser or should i expect it within SVG plugin ? I have seen the same sort of 'double' effort occuring in a variety of xml technologies; reading the XForms spec seems to be a very good example of where XSLT and XForms are sometimes performing very similar tasks, though slightly different for implementation purposes. there are some rather undesirable effects with the convergance of xml technologies ( gasp ), when done without any superstructure. issues ----------- - incomplete/incorrect support of specification of an external xml vocabulary, ie. XHTML in SVG. - double effort, when plugging in an external implementation of a specification would be cleaner and more efficient and reduce the risk of getting the spec implementation wrong. - confusion between xml as a DEFINITION versus xml as an IMPLEMENTATION, meta data is supposed to be one of the pillars of the semantic web, i see the current range of xml technologies as either a final or source format from which to either parse or transform from to deal with any specific implementation ( ex. XForms definition can be expressed as a webform or a pda form ). Currently the working groups of many xml specifications seem to be 'spiralling' into creating vocabularies that are not data centric, in other words there is poor seperation of data structure versus implementation details. - tight coupling within a specification with another specification, creates a brittle architecture and poor scalability. - XSLT will/should be the language of choice to transform the suite of xml technologies, currently XSLT is also being used ( for good or bad ) for dealing with larger problem domains that will/should be dealt with by XQuery ( hehe someday ). I think that the individual working groups need to recognize that XSLT (just like XPATH is adopted) functionality should be desired over any parallel effort, this would promote saner convergance. its obvious that there will be situations whereby 1 or more xml technologies will be authored and parsed in one environment, thusly they are expected to 'live' together ( ex. a web page with an SVG expression of an XForm definition that controls the generation of XHTML ). using XSLT as the glue, or 'conductor', of proceedings was quite effective in my rather poor example. a suggestion; maybe we need to have a mechanism that reuses namespace bindings for 'plugging-in' external xml parsers/clients. i wouldnt mind if this functionality is within XSLT or in xml as core. i am definately looking at this issue from an 'authoring' viewpoint, strong interoperable use of xml technologies is where we are all migrating to. thoughts ? cheers, jim fuller XSL-List info and archive: http://www.mulberrytech.com/xsl/xsl-list
Current Thread |
---|
|
<- Previous | Index | Next -> |
---|---|---|
Re: [xsl] Convert xml to PDF, Olivier Collioud | Thread | [xsl] How do you count nesting leve, J S Publications |
Re: [xsl] A Counter Variable in XSL, David Carlisle | Date | Re: [xsl] Convert xml to PDF, Jörg Heinicke |
Month |