RE: [ubl-dev] Proposal to Update UBL Lite from version 0.2 to version 0.3

[<MCRAWFORD@lmi.org>]

Stephen,

Can you please clarify what you mean by UBL Lite?  Is this a Stephen
Green effort, or a UBL sanctioned endeavor.  If the former rather than
the latter, perhaps a different name that does not imply UBL sanctioning
would be more appropriate.

Thanks, 


Mark
Mark R. Crawford
Senior Research Fellow - LMI XML Lead
W3C Advisory Committee, OASIS, RosettaNet Representative
Vice Chair - OASIS UBL TC 
Chair - UN/CEFACT XML Syntax Working Group
Editor - UN/CEFACT Core Components

 
LMI Government Consulting
2000 Corporate Ridge
McLean, VA 22102-7805
703.917.7177 Phone
703.655.4810 Wireless
The opportunity to make a difference has never been greater. 

www.lmi.org 

-----Original Message-----
From: Stephen Green [mailto:stephen_green@seventhproject.co.uk] 
Sent: Thursday, September 09, 2004 7:56 PM
To: ubl-dev@lists.oasis-open.org
Subject: Fw: [ubl-dev] Proposal to Update UBL Lite from version 0.2 to
version 0.3

Apologies in sending this again but I've just been informed (thanks Jon
on ubl list) that there can be spam-filter issues with an HTML version,
as I sent the first time. So just in case some didn't get this the first
time, sorry but I'll send it again.
It also
emphasises part of my point 2 below - to avoid sending the ubl lite
specs as html attachments and to revert to spreadsheets. Maybe XML
instead of spreadsheets?
Better for processing but harder to read - so maybe both.


Greetings


I'm proposing a further change to UBL Lite as follows:


1.              Change of Designation Rule in UBL Lite 'Recommended'

from

"Entities labelled R MUST NOT be ignored by receiving applications
conforming to the profile whereas others MAY be ignored"

to

"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