OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

ubl-cmsc message

[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