At 00/07/03 18:01 -0400, David RR Webber wrote:
>I would stand by my assertion that XSLT is a programmer toolset,
>and this is based on extensive XML/XSLT teaching, where
>non-technical audiences used to using EDI translation mapper
>technologies ask the question 'and we are supposed to do what with
>this now?'.
And I acknowledge I am unaware of the audiences to whom you've presented
this, so I accept your assessment of their reaction.
Personally, I have not presented XSLT as a programmer's tool set to my
audiences. So very many of my students are HTML users, not programmers,
who see the XSLT vocabulary as "just another vocabulary" within which they
use their familiar HTML vocabulary.
Acknowledging your audiences have been exposed to EDI translation mapper
technologies, I would suppose they may be unaware of markup technologies
.. so, yes, a new technology based on markup may appear quite foreign.
However, to work in the web world, those who are familiar with the concepts
and precepts of markup technologies do see the declarative nature of XSLT
as more like the declarative nature of HTML than the imperative nature of
JavaScript or other programming languages or their programming interfaces
such as the DOM.
>This is not a bad thing! Also I would expect solutions based on
>ebXML compliant technologies to more nearly match B2B
>information needs, than something like XSLT - which just
>because you add 'T' to the name, does not fundamentally
>alter that fact that the heritage is from markup stylesheet land
... but was split off as a separate non-stylesheet-specific
Recommendation. Remember that the XSL formatting vocabulary is, itself,
expressed using an XML vocabulary so all an XSLT stylesheet is for XSL
stylesheet technology is a method used for the transformation of instances
from one XML vocabulary (the user's) to another XML vocabulary (the XSL
FO's). When using other target vocabularies (say, an EDI's XML import
vocabulary), the transformation qualities of XSLT do not differ in their
effectiveness or appropriateness. Many people misconstrue this environment
based on only considering the one use of the XSL formatting vocabulary as a
target: which is stylesheet stuff.
Using the XSL formatting as a target is transforming one's own vocabulary
into the W3C vocabulary, and is no different from transforming one's own
vocabulary into any other arbitrary vocabulary. Indeed the document
element of an XSLT transformation specification can equally be
<xsl:transform> instead of <xsl:stylesheet> (identical semantics) to
support this notion of being an arbitrary transformation specification and
nothing to do with appearance.
>which is a whole different mindset to EDI, code and element,
>and business information interchanges.
I do not claim to know how different the mindset is required for these
aspects and how mapping technologies address the requirements of such
transformations, however, would not the XML casting of these concepts
change the nature of the transformation requirements to be those of
markup-related facilities and thus be independent of the subject domain of
the information so encoded? Regardless of whether we are talking EDI or
aircraft maintenance or automobile emissions or whatever?
Throughout this I am considering only XML-to-XML transformation, or as I
mentioned in my previous note (and supported by Kurt's note),
XML-to-some-other-format as a front-end to an application. I have assumed
the granularity of the markup used to capture the "EDI, code and element
and business information" is sufficiently detailed to reduce the mapping
requirements to merely markup manipulation and synthesis ... if the
information encoded is richer than the markup used to capture the encoding,
then XSLT could be very difficult to use and one falls back on more
difficult imperative techniques (which would have been required anyway if
the markup were not sufficiently rich). When the document models are
designed to capture the information required for successful EDI
interchange, I would hope translation and mapping requirements would be
considered in deciding the analysis and modeling granularity of the
information.
I'm enjoying this debate and hope it is seen as constructive.
................. Ken
--
G. Ken Holman mailto:[EMAIL PROTECTED]
Crane Softwrights Ltd. http://www.CraneSoftwrights.com/e/
Box 266, Kars, Ontario CANADA K0A-2E0 +1(613)489-0999 (Fax:-0995)
Web site: XSL/XML/DSSSL/SGML services, training, libraries, products.
Book: Practical Transformation Using XSLT and XPath ISBN1-894049-04-7
Next instructor-led training: 2000-09-19/20,2000-10-03,2000-10-04,
- 2000-10-05,2000-11-13,2001-01-27
------ XML/edi Group Discussion List ------
Homepage = http://www.XMLedi-Group.org
Unsubscribe = send email to: [EMAIL PROTECTED]
Leave the subject and body of the message blank
Questions/requests: [EMAIL PROTECTED]
To receive only one message per day (digest format)
send the following message to [EMAIL PROTECTED],
(leave the subject line blank)
digest xmledi-group your-email-address
To join the XML/edi Group complete the form located at:
http://www.xmledi-group.org/xmledigroup/mail1.htm
