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

MHonArc v2.5.0b2 -->

















ubl message






[Date Prev]
 | [Thread Prev]
 | [Thread Next]
 | [Date Next]

--

[Date Index]
 | [Thread Index]
 | [List Home]








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




From: "Michael Dill" <>
To: <>, <>
Date: Mon, 26 Sep 2005 00:18:21 +0200









Marty,
last week the CCTS update project team has 
apparently accepted my comments to remove the different handling of 
supplementary components compared with content components - but this will take 
time to become published. Thus the issue is still open for the current 
life.
Michael

  -----Urspr�ngliche Nachricht-----
Von: 
   [mailto:]
Gesendet: Sonntag, 
  25. September 2005 18:43
An: ; 
  
Betreff: 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, 
   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: 
       [mailto:]
Gesendet: 
      Freitag, 23. September 2005 14:26
An: 
      
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, 
       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


      
       
  
   







References:

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






[Date Prev]
 | [Thread Prev]
 | [Thread Next]
 | [Date Next]

--

[Date Index]
 | [Thread Index]
 | [List Home]