RE: [set] XSLT, abstraction layers and map problemstandardizations

["Moberg Dale" <dmoberg@axway.com>]

I said that I would try to write down some concerns about the
abstraction level of XSLT for use in defining maps that preserve some
semantic relations among data sets exchanged using XML instances.

The initial use case involves a transformation between GS1 XML and UBL,
or so it seemed to me from looking at the sample application.

Other semantic interoperability use cases might well involve
transforming to a relational data base schema from XML. Or
transformations from a more EDIFACT like syntax to an XML syntax. And so
on. While XSLT might allow some treatment of these use cases, it would
be pushing its intended range of application.

The OMG QVT standard that I mentioned has an implementation in some
eclipse modules (ATL is one). QVT certainly contains parts that abstract
away to rules that capture the transformation as relations, and so does
not commit to a specific syntax or transformation technology. XSLT is,
of course, one way to implement those rules for certain applications.
Thus the QVT approach has a higher abstraction level that subsumes XSLT
as one possible transformation technology. 

If we are going to build libraries, we might need some way to organize
various transformation technologies, including XSLT. Sets of QVT rules
might provide some modularity support.

However, we might regard connecting up XSLT with the abstractions of QVT
as a later project, and then retrofit the XSLTs that are produced in the
initial phases of SET to conform with QVT rule sets.

So I am not really insisting that we take on QVT initially, but perhaps
only give some consideration to what a later QVT refactoring might
benefit from when we build up XSLTs. 

(We can, of course, build importable sets of templates to give XSLTs
more modularity. And, addressing David's remarks a bit, CAM could
provide a possible way of organizing XSLT templates, and so might
accomplish some structuring that would be valuable in a future library
of transformational rules, and modules of rules, that we could retrieve
from a suitably indexed repository for assembly into a map for some
given transformational task.)




-----Original Message-----
From: Johann Hoechtl [mailto:johann.hoechtl@donau-uni.ac.at] 
Sent: Wednesday, December 03, 2008 12:25 AM
To: set@lists.oasis-open.org
Subject: Re: [set] XSLT, abstraction layers and map
problemstandardizations

Thank you David for this explanations. During the call I was interested
to hear Dale's opinion that XSLT will not suffice and the mentioned CXF
yet there was not enough time to ask further questions. This explains it
pretty well.

>>> "David RR Webber (XML)" <david@drrw.info> 29.11.2008 04:07 >>>

To Dale's point on the conference call.

 
In CAM templates we are using the CXF format of semantics of a schema as
an abstraction layer that is particularly easy to process using XSLT.
 
To see how CXF works - simply use the camprocessor toolset - 
 
http://sourceforge.net/projects/camprocessor/ 
 
and ingest your XSD schema into CAM template.  Then under Files / Export
you will see CXF as an option.
 
Save to that - and then open in your favourite XML editor tool.
 
Examining that you will see how the information in the schema is laid
out using XPath to associate elements and attributes in the schema
structure in a way that is simple for XSLT to recurse thru.
 
For example - when you use the View / Reports / Tabular report - all
that information is being formatted using XSLT from the CXF layout - and
runs to about 200 lines of XSLT.
 
For examples of the actual XSLT - you can pull these from the
camprocessor SVN library on SourceForge.
 
But more simply - whenever you use any of the tools in the camprocessor
toolset - you are running XSLT scripts in Saxon to achieve all of these
- against the CXF and CAM template formats.
 
Basically the CAM template is the human readable WYSIWYG format - and
the CXF is the same information in internal machine optimized format.
 
So - in summary - we already have this nice XSD abstraction approach
that is very XSLT friendly as part of the CAM specification work.
 
Thanks, DW
--------------------------------------------------------------------- To
unsubscribe from this mail list, you must leave the OASIS TC that
generates this mail. Follow this link to all your TCs in OASIS at:
https://www.oasis-open.org/apps/org/workgroup/portal/my_workgroups.php 


---------------------------------------------------------------------
To unsubscribe from this mail list, you must leave the OASIS TC that
generates this mail.  Follow this link to all your TCs in OASIS at:
https://www.oasis-open.org/apps/org/workgroup/portal/my_workgroups.php