[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Re: [ubl-comment] Customization limitations
Many thanks Ken. Still not sure I mean 'sanctioned subsets' as the main point of them would be that they would be standard document types in their own right so they could be referred to as a 'syntax' and with a separate namespace to ensure they would never contain additional entities except in the extension point. Their model would possibly mirror a mature subset though. Best regards Steve ---- Stephen D Green On 8 April 2014 16:22, G. Ken Holman <gkholman@cranesoftwrights.com> wrote: > 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]