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

 


Help: OASIS Mailing Lists Help | MarkMail Help

ubl-dev message

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


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




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