[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Re: [wsbpel] Issue - 11 Your opinion requested
Ron, Definately my thinking as well. You asked some good questions - see my notes below. Thanks, DW. Message text written by Ron Ten-Hove > David, +1, especially on externalising the mapping. We already attempt to loosely couple the process definition to the document types, via properties. >>> Concur Is the CAM ExternalMapping solution sufficiently stand-alone that we could adopt it for use in BPEL? (I suspect not, but optimism springs eternal.) >>> Interesting thoughts. The CAM structure is modular with sections - so there is nothing to stop you just having the minimal set of the Structures section and the Mappings section. We'd have to add this to the spec' as a lightweight extension usage case - but technically I don't see too many issues to doing this. We already have the notion of Levels to control the feature set we expect in an implementation. And we already have the notion of an <import> of a sub-assembly - so infact using CAM in this way would just be like doing an <import> into a BPEL script of the Mapping section only - plus whatever additional pieces you felt necessary to complete enough of the semantics to make the map of content work. <<< With an extensible mechanism, we will have to establish which particular mapping types MUST be supported in order to assure portability of definitions. It shouldn't be too difficult to come up with such a list; I'd suggest XSLT 1.0 and XPath 1.0 for starters. The list can be expanded in future versions of BPEL as things like XQuery and XSLT/XPath 2.0 are adopted, but not lock implementors into a restricted universe of options. >>> Agreed. We use the Level approach in CAM to document what implementations need to do at each level to be conformant. <<<
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]