[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Re: [ubl] Groups - UBL Post-Award Subcommittee Charter uploaded
It is a matter of "ownership"..
we state that the each SC is responsible for it's own set of "documents" and it is clear which SC "owns" that document and the related process model and documentation. This is clearly stated in the list of deliverable's and I think we all agree with that.
But the SC does not "own" any component in the common library because each SC is free to use these components where ever needed in line with the meaning of those components.
Because the SC does not own these components, it can not be be a deliverable of the SC to maintain and develop these common library components as is currently stated in the list of deliverable's. Because that might conflict with other SC's that are using these components, or that want to make their own components that might be identical in meaning.
That is why I think the list of deliverable's should be updated to clearly state that they can make a proposal to create or update components relevant to their process. And then it is up to the TC to determine what to do with that proposal. That way we can make sure there are no duplicate or nearly identical components end up in the common library which results in a better library.
Van: G. Ken Holman [firstname.lastname@example.org] namens G. Ken Holman [gkholman@CraneSoftwrights.com]
Verzonden: dinsdag 28 april 2015 18:03
Aan: Duvekot, Kees; Tim McGrath
Onderwerp: RE: [ubl] Groups - UBL Post-Award Subcommittee Charter uploaded
At 2015-04-28 07:26 +0000, Duvekot, Kees wrote:
>referring to "Post-Award Procurement components" in the common
>library could still signal that there is a Post-Award specific
>"subset" within the common library model.
I disagree ... I don't think "subset" is implied. Nothing says that
a Post-Award Procurement component is not also a Pre-Award
>I think that is not the case, and that the common library model
>spans the whole scope of UBL and the elements can be used by any
>document when relevant.
And I think anyone thinking about UBL knows that from the
deliverables created with the existence of subcommittees contributing
parts to the whole.
>Therefor I think the SC should make a proposal to the TC for changes
>to the common library model ... so that the impact of that change,
>or the interaction between documents of other SCs can be analysed
>That will lead to better understanding across all SC's and
>elimination of redundant/duplicate elements in the whole library.
I don't think that is necessary, as it is implied in the modus
operandi of the committee. Note the charters state that the SC is
not creating any schema, only semantic conceptual models. And the TC
process implies that subcommittees cannot make work products, only
the TC as a whole.
Can not it be assumed that a reader of the subcommittee charter would
know the operation of the technical committee as a whole?
I will ask TC Admin for guidance based on their experiences.
>And I assume that the same is also mentioned in the Pre-Award SC charter?
. . . . . . . . Ken
Check our site for free XML, XSLT, XSL-FO and UBL developer resources |
Free 5-hour lecture: http://www.CraneSoftwrights.com/links/video.htm |
Crane Softwrights Ltd. http://www.CraneSoftwrights.com/o/ |
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 has been checked for viruses by Avast antivirus software.
To unsubscribe from this mail list, you must leave the OASIS TC that
generates this mail. Follow this link to all your TCs in OASIS at: