RE: XML Implementation spec

[Bob Haugen <linkage@interaccess.com>]

Arofan,

Thank you for your patient explanations.  I'm coming from
the viewpoint of an object-oriented programmer who has
a Party object that can be a Buyer in one exchange
and a Supplier in another.

Do you encounter this situation?  How do you deal with it?

For example, I understood Commerce One was dealing with 
auto supply chains.  So you might have Bosch, who 
supplies General Motors and buys from Rockford Spring.

Is Bosch a SupplierParty or a BuyerParty?
Or does Bosch have an identity object that is separate from
either of those party objects, and those are more like Roles?
Or SupplierParty and BuyerParty are more like Decorators
than subclasses (as in the Design Pattern by that name),
where Bosch has a unified identity as a Party which supplies
the same underlying property values for each Decorator?
Or are you not concerned with Bosch's unified identity because
you are just sending messages wherein Bosch plays 
only one of those roles (per message) and the unified
identity is part of Bosch's internal systems?
Or something else?

I'm just trying to understand; I assume you have something
that works, at least in its context.

Thanks again,
Bob Haugen

-----Original Message-----
From:	Arofan Gregory [SMTP:arofan.gregory@commerceone.com]
Sent:	Friday, May 26, 2000 5:01 PM
To:	'Bob Haugen'; 'ebxml-core@lists.oasis-open.org'
Subject:	RE: XML Implementation spec

Bob:

It's really a combination of object subclassing and the way procesing
systems deal with this kind of object relationship. Most XML-based
processing systems manifest each element in an XML schema as a class. This
is how we process XML in Commerce One's products, and it's how BizTalk
processes XDR schemas, typically. The Party example fits xCBL well (C1's
business library) since we have Party - it's own class - as well as
BuyerParty - a subclass of Party - and SupplierParty - also a subclass of
Party. There is a processor that takes the XML business document and
instantiates a set of element classes according to what is in the received
document.

If I need to write code that will process either BuyerParty or SupplierParty
(a single set of code) I use the methods that exist in the superclass Party,
which are get() and set() calls for the values in the Party structure. Since
both BuyerParty and SupplierParty inherit these calls from a common
superclass, Party, I can process either BuyerParty or SupplierParty with the
same code. This is a very common way of processing XML in e-commerce systems
these days, for systems that support schemas (rather than DTDs).

Further, our generic validation engine - our XML schema parser - will allow
either BuyerParty or SupplierParty to be substituted in any content model
that has a requirement for an element of type Party, because we know that
the subclass has all the required fields of its superclass.

This is very much modelled after Java and its inheritance mechanisms.

Hope this helps to clarify!

Cheers,

Arofan Gregory