Or mandatory and optional components. If compliant with ebXML then
features (a,b,c,d) must be present, Does not preclude additions of
features (e,f,g,h).
A definition of a minimal set of components and configuration may be a
good idea however this conversation should be deferred to and when we
set up a TA list and TC. I like the directions and initial input we
have so far.
;-)
D
Matthew MacKenzie wrote:
> It was an example. Would it make sense to have an "ebXML architecture"
> which could be interpreted to allow using UDDI, SOAP and BPEL instead
> of ebReg+ebMS+ebBP? I think not.
>
> Implementability in a concrete sense means we need to make choices,
> and those choices should be ebXML components wherever possible.
>
> -Matt
> On Dec 22, 2003, at 12:56 PM, Farrukh Najmi wrote:
>
>
>
> Matthew MacKenzie wrote:
>
> If there is an ebXML Architecture, it should not be agnostic
> to implementation.
>
>
> I think I understand above to mean that ebXML Architecture should
> be implementable and not some pie-in-sky that has no basis in
> reality. If so I agree.
>
> In other words, ebxml-bp should be specified over BPEL.
>
>
> Now you have lost me. What does line above have to do with the
> first statement?
>
> --
> Farrukh
>
>
> ___________________________
> Matthew MacKenzie
> Senior Architect
> Intelligent Documents Business Unit
> Adobe Systems Canada Inc.
> http://www.adobe.com/
> 506 869.0175
>
--
Senior Standards Strategist
Adobe Systems, Inc.
http://www.adobe.com
