RE: XML Implementation spec

[Arofan Gregory <arofan.gregory@commerceone.com>]

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
 
-----Original Message-----
From: Bob Haugen [mailto:linkage@interaccess.com]
Sent: Friday, May 26, 2000 2:18 PM
To: 'ebxml-core@lists.oasis-open.org'
Subject: RE: XML Implementation spec


Arofan,

Does subclassing in core components mean something different
from subclassing in an object model?

For example, if I am an object of the Buyer subclass and then
I want to switch to being a Seller, I would need to change my
class (which is not supported very well in most object-oriented
languages).  I would be better off being an object of the class
Party and adopting Roles of Buyer and Seller, which I can
change at will.

But maybe I am applying object-thinking, and you are not
using the concept "subclass" in an object-oriented sense?

Confusedly,
Bob Haugen

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

Bob:

The point of subclassing is that the core information structure (the "Party"
information) would be the same whether the Party was acting as Buyer or
Seller. This way, it becomes possible to reuse the data structure of the
superclass in each of these otherwise disparate cases. That is the whole
point of subclassing - to allow re-use of the information in cases where
there is a different semantic associated with the same bits of data. So long
as the structure (at the level of the super-class) is common, the semantic
can be adjusted without making interoperability impossible.

Cheers,

Arofan Gregory

-----Original Message-----
From: Bob Haugen [mailto:linkage@interaccess.com]
Sent: Friday, May 26, 2000 1:26 PM
To: 'ebxml-core@lists.oasis-open.org'
Subject: RE: XML Implementation spec


Ernie Nishiseki wrote:
>Attached is a first draft of the XML Implementation Methodology
>specification.


Question:  in this document, Buyer and Seller are subclasses
of Party.  Is this the way the core component for Party will be
designed (I hadn't noticed it in other documents), or is that just 
an example of how to implement subclasses?

To put a point on the question, how could the same Party
be a Buyer in one exchange and a Seller in another,
if Buyer and Seller are subclasses?

Thanks,
Bob Haugen