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