[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Re: [ubl-comment] Customization limitations
Thank you, Stephen! I have created this ticket to cover off your additional point: https://tools.oasis-open.org/issues/browse/UBL-4 Again, we very much appreciate your contributions. . . . . . . . Ken At 2014-04-08 13:15 +0100, Stephen D Green wrote:
Many thanks, Ken, and UBL TC, for your response. Yes, there needs to be careful consideration of how calculation semantics are included in customizations and implementation guides and how the architectural aspects of the customization are impacted by these semantics, e.g. is any subset in a particular customization closed to further restriction, open to extension and in a conforming instance, is it open to inclusion of entities not specifically included in the subset but included in the superset / UBL Standard, etc.? There is one aspect of my comment, though, which, it occurs to me, perhaps isn't covered by the ticket: Perhaps my comment didn't highlight it enough, as it focussed on the calculation semantics, but as UBL standardization and broad implementation increases, I wanted to draw some critical review of the emphasis on subsets as a whole in UBL. See subject of comment. In light of the weaknesses of subsets in the way they can cause some complex problems when calculations, for example, are defined in the semantics of a subset, I think there needs to be review of whether the more mature subsets could now be promoted to becoming standard UBL documents in their own right. One reason I would give for this is that the semantics of a document instance based on the superset will be less prone to variations, in, for example, the calculation model, than with an instance based on a subset. That is not to say an implementation guide need not be provided separately, targeted at a particular user community, say, but it will be easier for such a guide to include a clearly defined calculation model when there is no risk that instances will include unexpected entities (outside of the extension point). Of course, the guide may still need to include something to handle extension point semantics (e.g. to forbid the need to include such extension entities in the calculation model for standard document totals, etc.). Alleviating the need for a subset (while still emphasising, perhaps, the importance of implementation guides for covering, say, calculation semantics) would help implementations, I propose, in this way, amongst others, and this in turn might promote further UBL adoption. I would suggest this might even conrtibute to a possible future UBL v3 (but that would be another comment altogether...). Many thanks All. ---- Stephen D Green On 8 April 2014 02:44, G. Ken Holman <gkholman@cranesoftwrights.com> wrote: > Thank you, very much, Stephen, for your post to the UBL Comment List. > > The committee considered your contribution during its meeting of March 26, > 2014: > > https://lists.oasis-open.org/archives/ubl/201403/msg00021.html > > Accordingly, we have created a ticket so as not to lose sight of your > contribution when it comes time to work on customization and implementation > guidelines: > > https://tools.oasis-open.org/issues/browse/UBL-3 > > We trust this will satisfy your comment, and we invite you to contribute > more thoughts in this regard for us to consider in the future. > > Thank you, again! We very much value your input. > > . . . . . . . . Ken > > > At 2014-03-22 10:48 +0000, Stephen D Green wrote: >> >> Dear UBL TC, >> >> This is a comment to point out a weakness in reliance on customization >> to implement UBL which might need to be noted in future documents >> about customization and implementation of UBL (perhaps if any >> revisions are made as a result of the PAS submission). >> >> This comment also incidentally supports the decision to exclude a >> formal calculation model from the UBL semantics so far. >> >> There seems to be a serious limitation in the subset concept typically >> applied to customizations, not only of UBL documents but perhaps more >> generally too, in that in order to define the semantics of a subset, >> there may be unintended variation introduced between the semantics of >> the subset and the semantics of the superset. When this semantics >> variation involves the calculation model (such as when a subset is >> made of a customization which includes a calculation model), I think >> it is likely to have adverse side-effects. >> >> For example, in a document there may be an entity to apply a rounding >> value to amount totals; if the subset does not include this entity but >> the subset includes a calculation model, it is possible that the >> calculation model will exclude the rounding value. This factor may be >> irrelevant if the subset does not allow inclusion of non-subset >> entities outside its own syntax in documents. However, if the subset >> does allow a document to include the rounding value then its semantics >> and in particular its calculation model will need to handle this as an >> issue. In such a case, I think UBL needs to warn implementers, the >> designers of the semantic subset need to be aware and make it clear >> how such a document is to be handled. >> >> The same applies, I think, to the case of multiple subsets where >> interoperability is sought between them. >> >> I suggest this be noted in future UBL documents and perhaps some other >> means be used to warn UBL implementers. >> >> Best regards >> ---- >> Stephen D Green
-- Public XSLT, XSL-FO, UBL & code list classes: Melbourne, AU May 2014 | Contact us for world-wide XML consulting and instructor-led training | Free 5-hour lecture: http://www.CraneSoftwrights.com/links/udemy.htm | Crane Softwrights Ltd. http://www.CraneSoftwrights.com/m/ | G. Ken Holman mailto:gkholman@CraneSoftwrights.com | Google+ profile: http://plus.google.com/+GKenHolman-Crane/about | Legal business disclaimers: http://www.CraneSoftwrights.com/legal | --- This email is free from viruses and malware because avast! Antivirus protection is active. http://www.avast.com
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]