[xsl] interoperable use of xml technologies

["cutlass" <cutlass at secure0 dot com>]

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