[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Re: [ubl-dev] Proposal to Update UBL Lite from version 0.2 to version0.3
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 > > >
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]