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

["Burcham, Bill" <Bill_Burcham@stercomm.com>]

Title: FW: Another item for issue tracking list.

It sure is good to have more experts evaluating our proposals.  Each of our proposals stand in various degrees of formalization.  The Paella proposal includes what could be called use-cases (see xpaths.txt) along with executable realizations of same, in the form of a little XSLT stylesheet (use-cases.xsl).  The latter can be run against each of the instance documents (ubl-doc.xml, company-{x|y|z}.xml) to demonstrate abilities of the proposed solution.

 

Arofan: could you please ask Mette Heddin to deconstruct her analysis a level or two by critiquing either a) the use-cases or b) their realization as XSLT or c) the demonstrated ability of the proposal at hand to address those use-cases.  Depending on where she thinks the proposal falls down then we may be able to address it with a) adding a use-case b) repairing the XSLT realization of the use-case to expose the shortcoming of the proposal, c) adjust the proposal so that its demonstrable abilities are less "very bad".

 

Said another way: viewed as a tiny formal system, the Paella proposal is fairly self-consistent.  That means that if the proposal isn't "good" then that is either because the system isn't really self-consistent (b above) ; or it is self-consistent but fails to model the right real-world problems (a above) ; or it is self-consistent, and represents the right real-world problems, but the test results have been misinterpreted (c above).

 

At the risk of stating the obvious, the benefit of deconstructing in this way is that it will lead us to capture use-cases we can agree on, in an executable form that can be applied to all the proposals.

 

-----Original Message-----
From: Gregory, Arofan [mailto:arofan.gregory@commerceone.com]
Sent: Monday, April 15, 2002 1:20 PM
To: 'ubl-ndrsc@lists.oasis-open.org'
Subject: [ubl-ndrsc] 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