[Fwd: Re: [ubl-dev] Suppose I am writing a process to accept orders.]

[Anne Hendry <anne.hendry@sun.com>]

  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.
> >
> >
> >
>
>
>