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


Help: OASIS Mailing Lists Help | MarkMail Help

ebxml-core message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]

Subject: Re: Syntax Free Models - was: [Fwd: Oracle Input for Core ComponentsWG]


> > > The hierarchy of standards is actually a hierarchy of processes - we
need to
> > > clearly distinguish this hierarchy from the hierarchy of message
> > > (unfortunately these seem to be mixed in many cases)
> >
> > I don't entirely understand your comment. Where do you fit a message
component which describes (i.e. further refines) a process)?
> > example: suppose you have a message called "order to buy or sell'.
Within that message, you specify (ie. refine) by saying it is for
> > instance a 'buy'.
> > In other words, sometimes messages (and as such one or more of their
components) describe part of a process. This relates to
> > defining how 'generic' a message will be.
> > Or did I completely misunderstood your comment?

To me buying and selling are different processes, but I can see why you
might want to use a single "order" form in some instances. In this case you
can use a property to distinguish between them at root level, e.g
Order[Type="ToBuy"] and Order[Type="ToSell"]. But notice the falacy of this
approach is that it would allow you to sell with out reference to what you
have bought at some point earlier in the process chain. (OK I know that this
is what you naughty stock market types always do, but this is not the normal
essence of trading!)


[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]

Search: Match: Sort by:
Words: | Help

Powered by eList eXpress LLC