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

 


Help: OASIS Mailing Lists Help | MarkMail Help

ubl message

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


Subject: Re: AW: [ubl] What to do with amountCodeListVersionID (was Minutes of Atlanti...


Michael,
 
If I understand you correctly this is just the point. Need to have fixed supplementary components that can be optionally included in elements of type 1 and type 2 usage of codes.
 
Unless, you create your own code list version in which case the supplementary components have to reference your organization and version info etc...
 
Marty
 
In a message dated 9/25/2005 8:16:11 AM Eastern Standard Time, dill2@gefeg.com writes:
BTW: are you aware that the current CCTS version 2.01 does not allow any restrcitions on supplemenary components other than enumerations? (see storage chapter)
Does this cause problems for specialized data types and your code list concepts?
Michael
-----Ursprüngliche Nachricht-----
Von: Burnsmarty@aol.com [mailto:Burnsmarty@aol.com]
Gesendet: Freitag, 23. September 2005 14:26
An: ubl@lists.oasis-open.org
Betreff: Re: [ubl] What to do with amountCodeListVersionID (was Minutes of Atlantic UB...

All,
 
It seems to me that the most important purpose of the supplementary components of code lists and other elements is for version control and traceability. So I would expect that anytime a code list is used, all of its supplementary components must be potentially present.
 
The use of "fixed" values in the schemas allow for the values of the supplementary components to be unambiguous as referenced by the schema, or at the option of the user, as included in the instance file. In either case, schema guarantees that these values are correct.
 
Also, why is it necessary to rename the version ID from a standard list to match the element name? Why not just include the attribute optionally by reference from the standard (or substitution) schema?
 
Marty
 
In a message dated 9/23/2005 6:01:17 A.M. Eastern Daylight Time, tmcgrath@portcomm.com.au writes:
the problem is that whatever we try and do we cannot stiil ensure that
we have enough attributes to unambiguously identify the code list used. 
so we can do what you suggest but still not solve the business requirement.

unfortunately code lists have no unique identification key. even the
name and the version ID is not enough.

some code lists (such as ISO currency codes) have alternate
representations (such as numeric as well as alphabetic codes).  where do
we specify that?  simply knowing it is ISO  4217 version 0.3 (or "2001")
is not sufficent to say what are legitimate values.

what is more there are no formal notations for specifying code list IDs
or versions IDs.  what if we have amountCurrencyCodeListVersionID="0.3"
and amountCurrencyCodeListVersionID="v0.3" and
amountCurrencyCodeListVersionID="2001" - are these equivalent?

creating a specialized (or what we now call "qualified") data type for
currency codes is an option but i suspect it needs more than just one
other attribute.

in the meantime we dont want this to hold up generating the first set of
schemas.

Can i suggest we revisit this (yet again!) when we have some sample
schemas and instances to talk to.

Note that we will be still having a UBL QualifiedDataTypes model and
schema module (for the code lists) so technically we should be able to
introduce this later without too much impact.

Stephen Green wrote:

>Minutes read:
>
>   "JB: So we can live with the ATG2 version of amount?
>
>   PB: Yes. We can live with the ATG2 way of signifying version
>   because of our new code list strategy.  Before, we could not
>   update the version, but with the new approach, this does not
>   appear to be a problem.
>
>   JB: Aside from code lists, then, have we now resolved all the
>   issues for schema generation at this point?
>
>   MG: Yes.
>
>   Due to a technical problem that prevented several members
>   attending meetings in Europe from dialing in to this meeting,
>   we did not have a quorum.  Voting members of the UBL TC have
>   one week to register objections to the PSC recommendation,
>   after which, if no objections have been received, the
>   recommendation will be considered adopted by the TC."
>
>
>My comment:
>
>Apart form changing a codelist version, how do users specify in an instance
>which codelist version they are using with this design/recommendation?
>Can they? and if so, How?
>
>I'd have to object (sorry folks) if this can't be answered satisfactorily.
>
>All the best
>
>Steve
>
>
>
>
>
>---------------------------------------------------------------------
>To unsubscribe from this mail list, you must leave the OASIS TC that
>generates this mail.  You may a link to this group and all your TCs in OASIS
>at:
>https://www.oasis-open.org/apps/org/workgroup/portal/my_workgroups.php
>
>

>

--
regards
tim mcgrath
phone: +618 93352228 
postal: po box 1289   fremantle    western australia 6160

DOCUMENT ENGINEERING: Analyzing and Designing Documents for Business Informatics and Web Services
http://mitpress.mit.edu/catalog/item/default.asp?sid=632C40AB-4E94-4930-A94E-22FF8CA5641F&ttype=2&tid=10476


---------------------------------------------------------------------
To unsubscribe from this mail list, you must leave the OASIS TC that
generates this mail.  You may a link to this group and all your TCs in OASIS
at:
https://www.oasis-open.org/apps/org/workgroup/portal/my_workgroups.php

 
 


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