OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.


Help: OASIS Mailing Lists Help | MarkMail Help

ubl-comment message

[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:


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,

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.

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]