Proposal to Update UBL Lite from version 0.2 to version 0.3

"Entities labelled R (R = 'RECOMMENDED') SHOULD NOT be ignored

by receiving applications conforming to the profile whereas others

MAY be ignored"

with the addition of a reference to RFC 2119:

"The keywords 'RECOMMENDED', 'SHOULD NOT' and 'MAY' are to be interpreted as

defined in the Internet Engineering Task Force (IETF) Request for Comment (RFC)

2119"

This is because, taken strictly, 'MUST NOT' would mean that an application

has to do something with each entity designated with that rule to comply

with the profile, even if there is no actual business reason for it to do so.

For example, the application may have no use for the GUID and would have

no reason to prevent it ignoring it but this rule might, unnecessarily, give the

impression that ignoring it might be counter to the specification of the profile.

While I think it unlikely that this would cause many problems, just in case

there is some sort of legal necessity or the like to be as unambiguous as

possible, I'd be disposed to make the change described.

Also the RFC 2119 keyword 'RECOMMENDED' is synonymous with 'SHOULD'

and so 'SHOULD NOT be ignored' is equivalent to 'RECOMMENDED'.

2. Improving use of UBL Lite with ebXML CPPA and BPSS

Another improvement follows from the observation that BPSS and CPPA

references to a profile layered over the UBL Schemas, as it were, may be

facilitated by the storage of specifying material such that it has a persistent

url (e.g. see mail to ubl-dev and ebxml-dev from Dale Moburg earlier today

http://lists.oasis-open.org/archives/ubl-dev/200409/msg00027.html ).

Without any better way to provide a persistant url / location for a document

specifying a version of UBL Lite, I would like to post the specification

documents to this list and reference versions of them by the resulting url's

produced by the OASIS ubl-dev mail list server. I appreciate that the server

may not always preserve these but that seems an acceptable risk.

It would seem to be best, for BPSS and CPPA, to give as precise a url as

possible. Providing the specifying model spreadsheets as HTML tables, as

done for version 0.2, does not seem to result in separate urls for each

table whereas I notice that attaching spreadsheets to the e-mail does.

The names produced in the urls might best be controlled with some sort

of naming rule which could then be used in other ways in documents such

as the BPSS and/or CPP/CPA. I'd propose a convention of

'UBL-1-0-Lite-0-3-Invoice' or all lower case 'ubl-1-0-lite-0-3-invoice' (not sure which).

Unfortunately, the list server changes the name of a spreadsheet from

'UBL-1-0-Lite-0-3-Invoice.xls' say to something like 'bin00015.bin'. The name

showing in the HTML is till 'UBL-1-0-Lite-0-3-Invoice.xls' but the url of the

href is the generalized name with the 'bin' extension so that is what will show in the

url which loactes the resource. However, the use of the convention as showing in the

messages may be enough to establish a pseudo-ID for the specification,

I would hope.

Maybe others have thoughts on this.

General Notes About the Lite Profile

I'd also note that there are no new Schemas for the Lite profile, as I've proposed it.

The only normative specifications are the Designation columns in the models

which label, for profile compliance, a subset of the BIEs as 'RECOMMENDED'.

I'd further note that there are two ways I can think of that implementers can

express their use of the profile and requirement for trading partners to do the same:

either using CPPA and perhaps BPSS from ebXML (perhaps with ebMS too)

or by including a satement to the same effect in another form of trading partner

agreement (e.g. to say that a certain product is being used which complies with

UBL Lite or just to say that compliance with UBL Lite is required in messages).

So the UBL documents with their standard Schemas and their UBL namespaces are

to be used with UBL Lite. It is in a layer above that where compliance to the profile

resides. Therefore Schema validation against UBL Schemas is unaffected but could

be followed in an implementation with validation to check for entities outside of the

profile's subset of 'RECOMMENDED' BIEs* and possibly throw a non-fatal exception

(perhaps outputting the entire instances in a human readable format for checking)

or just ignore the extra information (perhaps just logging the instance without any

interruption to the process). Either would be compliant with specification of the profile.

A third option would be to process parts of the message, e.g. where agreement had

been made that certain extras like CreditCard details be included. This too would be

valid.

[* BIE = Business Information Entity i.e. any element in the document and common aggregate

component and common basic component Schemas.]

It might be necessary to have legally sufficient clarity in the trading partner

agreement such that the party receiving the document, if the profile were ignored by the

sender contrary to the agreement (and the UBL Lite profile) - e.g. such that data were

included in the document outside of that designated 'RECOMMENDED' ('R') but which

included data vital to the business process (such as line level allowances or charges

not designated 'R') - that in any such case the receiver would have legal recourse and

protection. I'm no lawyer so I'd leave that to those who write such agreements but

from experience I would believe that this is quite feasible with UBL Lite, provided it

can become recognised, accessible and sufficiently well specified without ambiguity.

Now having a basic starting specification version (aware that it has been mainly my

own design till now, with appreciated advice), I'd really like to start seeking more

actively further improvement and input from others. Those of us who started the concept

felt it necessary first to put out a 'strawman' but it turned out to be a little more positive

than that due to the pressing need to have something to potentially implement.

Please feel free to comment on the content of this subset if you feel it should be changed

or to suggest ways the concept might be taken forward and improved as a standard.

I'd already feel confident with implementing this with trading partners since I believe it is along

the lines of any such subset which might be potentially part of a trading partner agreement.

It's strength would be in its broadness of applicability, especially as a horizontal, cross-context

profile for any who wish to use it.

However, I urge that there be no input contrary to the same IPR basis which UBL itself has.

It was intended that UBL Lite become a 'community' project but the fact that it is outside

the requirement for OASIS membership would seem to require special care about keeping

the IPR and openness in full accord with that of UBL and OASIS such that it be possible

that it be adopted into UBL or a similar policy OASIS TC, if this is necessary to its future

usefulness. It should also be remembered that there are implications regarding its relationship

to OASIS due to its name 'UBL Lite' including 'UBL'. As such, I'd like to know what implications

there would be to somehow adding the OASIS copyright, etc headings to the profile and I'll

try to find this out.

Regards

Stephen Green

ubl-dev message