[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
Subject: RE: [ubl-cmsc] Issues with ebXML Document
I'm a little confused. My first reaction would be to say that Rules contain Conditions, nested if necessary inside And and Or tags to represent conjunctions and disjunctions, and a set of Action tags that specify the actions to be performed, in the right order. The Order attribute should be used in the (presumably exceptional) case where a specific order must be imposed on different rules. I believe this is basically the way the ebXML spec works, right? Why would we need additional hierarchy in the rules themselves. This could turn out to be exceptionally inflexible, besides the copying/pasting consideration, if a rules is meant to be used alongside different rules in different cirumstances. Matt > -----Original Message----- > From: Eduardo Gutentag [mailto:eduardo.gutentag@sun.com] > Sent: Saturday, November 17, 2001 1:09 AM > To: Matthew Gertner > Cc: 'ubl-cmsc@lists.oasis-open.org' > Subject: Re: [ubl-cmsc] Issues with ebXML Document > > > Matthew Gertner wrote: > > > > 8) Assuming that we decide to start from the Vienna > document, what is the > > list of features in the Context rules that people think are broken? > > > > Note: We may end up folding this into 1), but let's discuss them > > individually for now. > > > > I think the first think we should take a hard look at is the > <Condition> element. > Originally this was an empty element, contained in <Rule>. > That is, for each > <Rule> there was one <Condition>. A way to order the rules, > so that different > conditions were applied in a pre-determined sequence, was > needed, so the order > attribute to <Rule> was added. Later on <Condition> became a > true container, and > there was no indication that a <Rule> could not contain more > than one <Condition> > or that a <Condition> could not contain another <Condition>. > > It seems to me that the first method had the advantage of > simplicity and > modularity (in that you could actually copy and paste rules > from one document > to another without having to worry too much about unintended > consequences). > However, there was no way to express hierarchies or sequence > of actions > other than through the "order" element. > > The second method, while allowing the direct expression of > hierarchies through > document hierarchy, has the distinct disadvantage of > presenting obstacles to > simple copy and paste. I'm not convinced, however, that this > is a practical > disadvantage (as opposed to theoretical). But if we are to > retain this second > method, then we have to re-examine the need for the "apply" > attribute as well as > "order". > > ---------------------------------------------------------------- > > To subscribe or unsubscribe from this elist use the subscription > > manager: <http://lists.oasis-open.org/ob/adm.pl> > > -- > Eduardo Gutentag | e-mail: > eduardo.gutentag@Sun.COM > XML Technology Center | Phone: (510) 986-3651 x73651 > Sun Microsystems Inc. | >
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
Powered by eList eXpress LLC