Re: [ubl-dev] Proposal to Update UBL Lite from version 0.2 to version0.3

[David RR Webber <david@drrw.info>]

Perhaps - UBL-Lite = Quick Start - might be a better notion....

DW

Stephen Green wrote:

>Mark
>
>Thanks for letting me clarify this (it's been a bit too much me I guess).
>This was taken to ubl-dev at the request / suggestion of the UBL TC
>representation at the UBL closing plenary in Hong Kong in May
>
>final slide in this May 2004 UBL closing plenary report
> http://www.oasis-open.org/committees/download.php/6848/plen-rpt-20040514.pdf
>
>Although it has looked recently like it is just Stephen Green   :-(    it has
>had involvement from many UBL TC members and associates and started 
>out of the public review comments. The intention has been that this, besides
>addressing concerns about barriers to entry to SMEs adopting UBL, should
>be first of a potential series of profiles and might be something of a pathfinder.
>
>Sincere apologies that my 'driving' or championing this has looked like
>a personal project using UBL's name but the name wasn't my idea (though
>I did deem it suitable for the purpose) and I've only put so much into it
>because those of us pushing it thought it best to make a working model
>as the first stage, then invite comment to that model. I would personally like
>to find out how the UBL TC feels now about this profile and it might be best
>if I could hand ownership of it back to the TC, not least for the sake of IPR issues
>and the UBL name.
>
>All the best
>
>Stephen Green
> 
>
>  
>
>>>><MCRAWFORD@lmi.org> 10/09/04 12:44:28 >>>
>>>>        
>>>>
>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
>
>  
>