Suppose I am writing a process to accept orders.

["Jeffrey P. Silverstone" <jps-oasis@margreta.com>]

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.