[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: RE: [ubl] The Unique Identifier rathole - was: Re: [ubl] Missing Schema Annotations and other schema matters
Tim, If a Registry only contains approved Core Components, then you are correct that the DEN serves as the Unique Identifier for storage. When however, you add change requests for approved core components, the DEN is no longer unique if there is a pending request to change an existing approved core component. This situation results in the need for an additional Unique Identifier. After detailed and lengthy discussion during a Atlantic TC call, the members decided that it would be unacceptable for any additional content to be added to a previously approved UBL standard. This included any possible additional Unique Identifiers to satisfy a future registry. The feeling of the TC was that published approved standards should not be changed after the fact. Regards, Sylvia -----Original Message----- From: Tim McGrath [mailto:tmcgrath@portcomm.com.au] Sent: Thursday, May 18, 2006 11:47 PM To: ubl@lists.oasis-open.org Subject: [ubl] The Unique Identifier rathole - was: Re: [ubl] Missing Schema Annotations and other schema matters i dont want to nit pick here but the CCTS only mandates a Unique Identifier for either BIEs or CCs when it is to be stored in a Registry. We have been discussing this ad nauseam since 2002. i dont want to go over it again (but i will ;-) ). in terms of outcomes i agree with what Syvlia says. we will generate some numbers from EDIFIX and use these in our schemas but I dont think we are kidding anyone that they will actually be useful or maintainable. They are to stop us having this debate every time we do a review. CCTS (2.01) defines a Unique Identifier as "The identifier that references a Registry Class instance in a universally unique and unambiguous way." That is, the storage/registry identifier Stephen noted earlier. Nothing to do with the defintion of a BIE or CC. So it probably best not to call anything a Unique Identifier unless it is the storage key for a Registry Class. As far as identifying definitions of BIE and CCs, the CCTS says when Applying the Naming Convention (Figure 5-4 ) - "Step 6 Assign Unique Identifier to the New Item" - this suggests its storage into a registry. However, in section 5.3.1 CCTS goes on to say "Step 6. Assign a Temporary Identifier to the new item in the form of a 6 digit alphanumeric string, chosen at the discretion of the user." These temporary identifiers are also used in the examples of core component catalogues. But this identifier does not form part of the Core Components and Data Types Metamodel (Figure 6-1.) of CCTS. So I am not sure when we started thinking of them as being mandatory. In fact i am not aware anyone (including the TBG groups) who actually uses these temporary 6 character strings. I suspect the motivation for this was to make harmonization easier. So it is worth noting that the new TBG17 format now requires a UUID or GUID type identifier (eg. cdf11383-243a-4b7e-a573-f73c8415743b) of any BIE or CC from its submitters. Maybe this will make it into the next CCTS but it isn't in 2.01. I suspect the reason this is such a grey area is because we dont actually need another identifier for BIE or CCs. That is what the Dictionary Entry Name does. Commonsense tells us that having 2 "unique" identifiers is unnecessary and potentially confusing when we try and maintain these things. And it doesn't matter if this identifier is numeric, english terms or hebrew - we only need one of them. And as we must have a Dictionary Entry Name, lets make it that one. Sylvia Webb wrote: >Stephen, > >Unique Identifiers are mandatory per the NDR. See the DOC "X" rules. >They are also mandatory in CCTS. > >They were not included in the first public review schema because we had >decided not to include them in UBL 1.0, and, GEFEG was not given enough >time to include them after we decided to do so for UBL 2.0. > >Unique Identifiers will be in the data models and auto generated in the >schema for the next public review. > >With respect to the extension point, I would suggest that you read the >CTD and GXS rules in the last NDR draft to determine if your questions >are answered. > >Regards, >Sylvia > >-----Original Message----- >From: stephen.green@systml.co.uk [mailto:stephen.green@systml.co.uk] >Sent: Thursday, May 18, 2006 7:33 AM >To: ubl@lists.oasis-open.org >Subject: [ubl] Missing Schema Annotations and other schema matters > >Folks > >Hi. Just becoming aware of some possibly outstanding matters needing >resolution before prd2 schemas can be generated (?) > >Did we not decide to have version info in each complex type? > - we have this in the spreadsheets but it doesn't appear in > the schemas for the first prd > >What was decided about UIDs for each complex type? It has just come up >on ubl-dev >http://lists.oasis-open.org/archives/ubl-dev/200605/msg00247.html >and it may be we were inaccurate in thinking this might be added when >to documents are entered into an ebXML registry. It seems they should >be in schemas in the first place and some things might depend on them >being being there in CCTS-compliant schemas > >A third item which may need resolving is how the extension point >element is added. Do we have a firm decision (discussion is going on on >ubl-dev about this too >http://lists.oasis-open.org/archives/ubl-dev/200605/threads.html#00243 >) > >Regarding the issues list, I'm unclear about what is intended with the >Extension ABIE mentioned. Will this be an extension point itself or >just metadata about the use of the extension point? Hopefully the >latter (otherwise there would be CCTS-compliance problems of course). > >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 > > > > >--------------------------------------------------------------------- >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 web: http://www.portcomm.com.au/tmcgrath --------------------------------------------------------------------- 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]