[ubl-ndrsc] FW: Another item for issue tracking list.

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

Title: FW: Another item for issue tracking list.

Folks:

Here's an opinion from the Commerce One woman who does all of our schema-based data binding to java.

She's underwhelmed with the abstract-type approach (Paella), and she comes at this from an eminently practical point of view (she's done java development for both SOX and XSD at this point, and is one of my go-to engineers for the reality of some of the stuff we come up with in UBL NDR.)

For what its worth...

Cheers,

Arofan

 -----Original Message-----
From:   Hedin, Mette 
Sent:   Monday, April 15, 2002 11:16 AM
To:     Gregory, Arofan; Holmes, Alex; Burdett, David; Mathur, Sandeep; Rosenthal, Karen; Hsu, Meichun; Kasi, Jay; Gandel, Christine; Leventhal, Michael; Blum, Adam; Ingersoll, Chris

Subject:        RE: Another item for issue tracking list.

Just to add my two cents to the empty content model approach. I have always found this to be a very bad approach.

For example, you have a type foo, which has no content, and is abstract. Then you declare fooOne, which extends foo with the content (a, b, c). The you declare fooTwo, which extends foo with the content (d|e|f). This means that you can encounter either one or the other of two completely different content models. Since the base type does not declare any content, you have just told your application that you can not be bothered telling it beforehand what content it should process, and that it will have to expect any content, be it fooOne, or fooTwo, or some user defined extension which it does not know about and may be written two years into the future.

This approach, along with any, anyAttribute and anyType, is just a way of chickening out of adding any useful content. For the sake of useful application processing, as much as possible should be in a base content model, and extensions may be added later on, but then the extension write will have to be aware that both sender and reciever will have to be aware of the content, and that it is done on a voluntary basis.

Replacing the entire namespace with new definitions that enforce the extensions is fine, but that is a major version, and does require re-coding the application.

Mette Hedin