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

[Eduardo Gutentag <eduardo.gutentag@sun.com>]

Bill,

at the risk of appearing to support a different model, or of appearing to
be attacking Paella (which at this point I'm not ready to do, one way or
another), you forgot to include possibility (d) in your message, namely
the possibility that while the proposal may satisfy (a), (b) and (c) entirely,
it has undesirable side effects (which is what I read in Mette's
undeconstructed critique)

Eduardo

Burcham, Bill wrote:
> 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
> 
> 



-- 
Eduardo Gutentag               |         e-mail: eduardo.gutentag@Sun.COM
XML Technology Center          |         Phone:  (510) 986-3651
Sun Microsystems Inc.          |