Re: [ubl-comment] Customization limitations

[Stephen D Green <stephengreenubl@gmail.com>]

Regarding my last update to my comment, it might be that it would
require some technical issues to be overcome, such as how to have
'core' aggregates (i.e. aggregates whose model accords with subset)
coexist with previously modelled (superset) aggregates. So I accept
the TC will have such problems to solve if this comment were accepted.
One way to do it might be to have a second spreadsheet and produce a
second common aggregate schema. Another might be to produce a UBL
version 3. Either way, it seems feasible to find a solution to these
technicalities.
----
Stephen D Green


On 8 April 2014 17:12, Stephen D Green <stephengreenubl@gmail.com> wrote:
> 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
>>