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] | [List Home]

Subject: Re: [ubl-cmsc] [Fwd: Re: [ubl-dev] Suppose I am writing a process toaccept orders.]

Without going into specifying an example (but I'd be more than glad
to see someone to do so ;) ), I believe a possible response to
this query would be:


the sentence you quote from Section 3.2 is a condensed way of saying:

"If the user wishes to require the use of the derived type, blocking the
possibility of using the original type in an instance, a new derived type
must be created from the Order type in the following manner: first derive
by restriction, eliminating the element referring to ubl:PartyType from
the myns:MyOrderType, then derive by extension adding an element that refers to


Does anybody disagree with this? Would the addition of an
<xsd:element ref="myns:MyPartyTpe"> be illegal at this point, as Jeffrey


Anne Hendry wrote:
>  Hi,
> Here are some CM questions.  There are several ways we can handle the 
> response.
> Generally, we had agreed that ubl-dev responses would be handled through 
> ISC,
> but in order not to become a bottleneck it's fine with me if you pick 
> one person
> in CM to respond directly to this on ubl-dev.  Alternatively, I can post 
> the initial
> response on ubl-dev and then suggest further discussion happen on the 
> ubl-cmsc
> alias (possibly requiring this person to join cmsc).  Some of the 
> questions coming
> in through ubl-dev are clearly CM-related, and others cross over to NDR and
> LCSC, so we'll have to play this by ear.  I think it will take 
> engagement of all the
> SCs to respond to the incoming questions in a timely manner from now 
> until the
> final release.
> FYI, I'm intending on putting many of these incoming questions in the 
> technical FAQ.
> Thanks,
> -A
> -------- Original Message --------
> Subject: Re: [ubl-dev] Suppose I am writing a process to accept orders.
> Date: Sat, 3 Jan 2004 11:49:29 -0500
> From: "Jeffrey P. Silverstone" <jps-oasis@margreta.com>
> To: <anne.hendry@sun.com>
> References: <002101c3cfe3$53e813b0$e0391bac@ADS004> 
> <3FF52D1C.6040004@sun.com>
> Thank you for pointing me to the CM document. I had not read this 
> version of
> it.
> It says, in section 3.2, that:
> "If the user wishes to require the use of the derived type, blocking the
> possibility of using the original type in an instance, a new derived type
> must be created from the Order type using refinement and specifying that 
> the
> MyPartyType must used."
> This document needs an example of that.
> Using the examples that are in the document, suppose I want to create a
> mynamespace:MyOrderType that requires use of mynamespace:MyPartyType (in
> place of ubl:PartyType). Suppose that there is a ubl:PartyType is directly
> referred to in ubl:OrderType . Also suppose that mynamespace:MyPartyType is
> derived by restriction from ubl:PartyType . I do not understand how
> mynamespace:MyOrderType relates to ubl:OrderType . I do not believe that it
> is derived by restriction from ubl:OrderType because it has this labeled
> entity declared in it (mynamespace:MyPartyType) which is considered an
> illegal new element, even though it happens to be derived from
> ubl:OrderType. Note that this problem only happens because these types are
> given global names, if ubl:OrderType contained an entity called Party which
> was local to ubl:Order, one could restrict Party to one's hearts content.
> It is quite possible that my understanding of derivation by restriction is
> incorrect; the XSD standard is difficult to read. Please let me know 
> where I
> am wrong.
> I am not, at this point, looking at relaxing the required elements in any
> way, only tightening them; so that any document that I consider a valid
> order, would (with possible namespace name changes only) be considered a
> valid UBL order. It is possible that
> http://lists.oasis-open.org/archives/ubl-lcsc/200312/msg00009.html covers
> this issue, but it looks to me to cover closely related issues and not this
> one.
> -- Jeffrey
> ----- Original Message ----- From: "Anne Hendry" To: "Jeffrey P. 
> Silverstone" Cc: Sent: Friday, January 02, 2004 3:34 AM
> Subject: Re: [ubl-dev] Suppose I am writing a process to accept orders.
>> Hi Jeffrey,
>> I couldn't tell from your posting if you've read the draft of the
>> Guidelines for
>> Customization of UBL Schemas (available in the 'cm' subdirectory of the
>> Beta release) which lays out the current rules for customizing UBL.
>> If you are talking about further restriction of optional elements,
> according
>> to the Guidelines (section 3.1.2) you can change the cardinality to
>> remove an optional element.  However issues with derivation by
>> restriction were also noted in email sent to the lcsc list on December 
>> 16:
>> http://lists.oasis-open.org/archives/ubl-lcsc/200312/msg00009.html.
>> These have been forwarded to the general ubl alias for discussion.
>> If you are referrning specifically to required elements (cardinality
>> 1..x) you will
>> probably be interested in tracking a posting that was made to the
>> Implementation SC
>> last week about the possibility of there being too many mandatory
>> entities in the
>> current model.  This will be discussed in the LCSC over the coming weeks.
>> UBL is just now considering the issues related to customization so you
>> can be
>> sure there will be more information on this in the upcoming weeks/months.
>> You can track these discussions and decisions in the subcommittee mail
>> lists.
>> -Anne
>> Jeffrey P. Silverstone wrote:
>> >Sorry if this is a dumb question:
>> >
>> >I am thinking of writing a prototype web service to accept an order. 
>> This
> is
>> >a front end to an existing system that I don't want to reengineer. The
>> >system accepts the order and uses a separate system to invoice the
> customer.
>> >Of course the SOAP body should be urn:oasis:names:tc:ubl:Order:1:0-beta
>> >compliant.
>> >
>> >I cannot use a lot of the optional information that could be sent to me
>> >under UBL. For example, I do not wish to accept any "CancelledByDate"
> codes
>> >in my order because to accept it would imply that my system can honor 
>> the
>> >request to cancel the order if the order is not satisfied. My existing
>> >system does not have that capability and we have no customer demand for
> it
>> >at this point.
>> >
>> >Also, for example, I have no way to accept from the purchaser 
>> information
>> >about costs and taxes. While it would be a nice feature to take their
>> >estimates and validate them against my price list, that is not likely to
> be
>> >used by my customer base and so I would rather make it clear to the
> customer
>> >that their order should not include price info because I will compute an
>> >invoice which they can pay.
>> >
>> >Given that I care about only one third of the fields in the standard, 
>> how
>> >should I deal with restricting what I can accept. I can publish that 
>> I am
>> >accepting the whole spec and then kick back errors for each field that I
>> >don't support. Alternatively, I can publish my own schema which happens
> to
>> >be a restriction of the UBL schema.
>> >
>> >As far as I know, I can't make a formal restriction on
>> >urn:oasis:names:tc:ubl:Order:1:0-beta because I would then be unable to
>> >restrict elements like OrderLine, which are defined in
>> >urn:oasis:names:tc:ubl:CommonAggregateTypes:1:0-beta .
>> >
>> >At this point I am lost.
>> >
>> >
>> >
> To unsubscribe from this mailing list (and be removed from the roster of 
> the OASIS TC), go to 
> http://www.oasis-open.org/apps/org/workgroup/ubl-cmsc/members/leave_workgroup.php. 

Eduardo Gutentag               |         e-mail: eduardo.gutentag@Sun.COM
Web Technologies and Standards |         Phone:  +1 510 550 4616 x31442
Sun Microsystems Inc.          |

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