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:]
Sent: Monday, April 15, 2002
1:20 PM
To: ''
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
