[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Proposal to Update UBL Lite from version 0.2 to version 0.3
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
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
|
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]