[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
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]