[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: ------------------ Jeffrey, 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 myns:MyPartyType. ------------------- Does anybody disagree with this? Would the addition of an <xsd:element ref="myns:MyPartyTpe"> be illegal at this point, as Jeffrey claims? Thanks. 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. | W3C AC Rep / OASIS BoD
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]