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

Dale,

 

Thanks for the clarifications.  I'm not sure we need to go down the XSLT path itself.  In CAM we are using XPath expressions to capture the relationships around content and business rules.

 

Commercially Oracle have their mapper product that generates XSLT to morph between target formats - and works using the familiar visual drag and drop metaphor between left and right hand panels (can we claim to have "invented" that also?!?)

 

Historically I've tended to steer clear of actual formal mapping challenges.  In part because I have two patents issued on this - that are now referenced by 39 other patents (unbelievable nonsense!).

 

So - my focus has been in developing templates that provide all the mechanisms and support for mapping - but are not actually mapping.  Therefore - folks can implement their own mapping solutions from what we are providing - without us having to go into that part.  XSD of course is walking a similar balancing act.

 

Also historically there are so many 1,000's of mapping solutions - and what they all lack is a common open public standard for expressing the actual content and assembly rules.  That is why we developed CAM the way we have - so there is an open way for people to exchange templates - that then mappers can quickly and easily utilize to automate the associated exchanges and content morphing.

 

I'd suggest that this is the better path for SET to tread also.

 

What I'm particularly interested in is CONTENT ASSEMBLY.  This is the last frontier here - CAM is covering off all the other aspects - but allowing people to rapidly and easily identify existing components - then integrate these in a consistent way - into their own exchange templates.  Consistent content assembly makes for easy mapping to physical applications!

 

Experts who are familiar with all the various nuances and domains can do this today manually.  However - how do we facilitiate this for the majority of practitioners - rather than a few?  NIEM.gov is facing this exact challenge today.  They have a formal procedure that works manually - but take months to master and do.

 

I have a draft internal conceptual design done - that hopefully I will be able to share with the SET and CAM communities here as we move forward.  However - as ever - establishing the focus and objectives is the first need.  What exactly are we aiming to build and who is the audience?  Once we have that agreed upon here - then we can move to the next phase - implementation!

 

Hope that is helpful.

 

Thanks, DW 

 

 

-------- Original Message --------
Subject: RE: [set] XSLT, abstraction layers and map
problemstandardizations
From: "Moberg Dale" <>
Date: Wed, December 03, 2008 10:12 am
To: "Johann Hoechtl" <>,
<>

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:] 
Sent: Wednesday, December 03, 2008 12:25 AM
To: 
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)" <> 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 

---------------------------------------------------------------------
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