The wsdl files provided at http://www.omg.org/spec/CTS2/1.1/ are not correct. #
We tried to generate java services with wsdl2java using these wsdl and xsd files but got errors due to faulty namespace settings and incorrect fault settings in the methods.

Where can we obtain the correct wsdl files to implement CTS2 specification conform soap services?

This is my OMG Architecture Board review of:

CTS2 XML to JSON Transformation Rules RFC (2nd Rdg) ad/13-09-04
Inventory ad/13-09-05

Here are the comments I did have - mostly minor, and all addressable during finalisation:

1. PDF page 7. For reference, OMG's office has moved: http://www.omg.org/contact.htm

2. Section 1 (Scope), PDF page 8. It would be useful to have definitive references to Badgerfish & Parker, the XML to JSON transformation conventions mentioned. It would also be useful to include one or two sentences explaining why they aren't thought suitable for CTS2 XML.

3. Section 3 (Normative references), PDF page 8. We definitely need a normative reference for JSON. One possibility is IETF RFC 4627 (July 2006):

http://www.ietf.org/rfc/rfc4627.txt

However, it looks as though ECMA has just published a JSON specification as ECMA 404 (an amusing coincidence, no doubt):

http://www.ecma-international.org/publications/files/ECMA-ST/ECMA-404.pdf

Is either of these an appropriate reference?

4. Section 6.2 (Specification adoption plan), PDF page 9.

The FTF process is designed to accommodate a specification adopted with the intention of merging it into an existing specification, as here. We simply charter an FTF that takes as input both the newly-adopted specification (in this case, the XML to JSON mapping RFC) and the already-adopted specification with which it is being merged (the CTS2 specification), and delivers as its result the merged specification (along with a finalisation report).

In this case, we should simply dissolve the CTS2 1.2 RTF, and charter an FTF that takes the XML/JSON RFC and CTS 1.1 as inputs, and delivers CTS 1.2 (including the JSON mapping) as its result (along with a finalisation report that tracks all the changes made to CTS 1.1 and to the RFC).

This is basically what you have proposed with the "common convenience document", but without the complication of having a separate RTF and FTF.

5. Section 6.4 (Patents containing essential claims). Unfortunately, we can't say that there are definitely none. The best we can say is that there are "none known to the authors". (But that's still useful to know).

6. Section B2 (Transformation patterns and Rules). I'm not an expert, but this all looks reasonable to me. However, "shall" should be used to express the rules instead of "will". For example "Repeating XML attribute values shall be treated as a single JSONValue.", "XML comments and processing instructions shall be ignored.", "The following JSONStringCharacters shall be escaped:" It's just a style issue - the meaning is already clear, and not affected by the change.

1. Address of the OMG office changed in RFC
Delete: Section B4, which referenced the emacs document was deleted and the following normative reference:
The JSON Data Interchange Format 1st Edition / October 2013. http://www.ecma-international.org/publications/files/ECMA-ST/ECMA-404.pdf
Was added to section 3

The reference in B4 should instead be added to section 3 (assuming it is normative)

The reference in B4 was deleted and a subsequent, normative reference was added to section 3:

Rule 10 example uses xsi2:nill – I think this should be xsi2:nil (only one L)

Change "xsi:nill" to "xsi:nil" in 4 places on Rule 10

Rule 10 does not cover the case where the removal of namespaces causes names to be indistinguishable (that’s the point of namespaces after all). Do such now-identical names then get treated as “arrays” per Rule 7. Or is this disallowed (similar to B3 rule 2)? This needs clarifying

Rule 10 included the statement “This rule is specific to the CTS2 specification. Other OMG specifications may choose the option to keep the namespace.” As, for the time being, this is a CTS2 only specification, the statement above was removed and, instead, a third B3 rule was added

The following in rule 10 is very unclear “In certain situations, this may cause issues for opaque data”

Remove the sentence as it is already addressed in the _CDATA section

Rule 10: it says to remove the “namespace prefixes” but the examples show removal of complete namespace declarations not just the prefix

The previous sentence states “XML namespaces are removed in the JSON.” We have already added the caveat involving _CDATA (issue 19305), but do need to add one additional exception for the root namespace

There seems to be a conflict between rule 10 which seems to state to strip all XML namespaces, and rule 13 which says to retain them if they are in _CDATA

There seems to be a conflict between rule 10 which seems to state to strip all XML namespaces, and rule 13 which says to retain them if they are in _CDATA

The documents referenced in Rule 12 should appear in the normative references section

References added (the first one was already added from Issue 19306)

B2 rule 7: I’m not aware of such a thing as an “XML array”

Reworded to clarify the intent

Section 7 has the wrong document number for CTS2 – it should be formal/13-12-01

Fix document number

The Normative References in section 3 must be added to the Normative References section in the main CTS2 spec. However section 7 does not describe such a change

Add a section to the revision document saying to add a section to the CTS2 document that contains the normative references in the annex.

And in fact the “Plan” in 6.2 with the RTF working in parallel is not being followed at all. The whole section is at variance with reality and people reading this document coming out of the FTF could get very confused as to what is happening.

This had been corrected as an earlier issue reported by Andrew Watson

6.2 references “The FTF beta document” but this is not referenced by document number – nor does it seem to exist as per comments above

Change to “this submission"

Section 1: should rephrase “this submission” – it’s now a specification

revised

Looking at 11-06-20.xml, I see elements such as <thecustomprofile:interface base_Class="EAID_F37A3B0D_CFE6_448a_A95F_26FDC113F2A2"/>, which are EA-specific representations. This needs to be fixed to be properly XMI compliant.

PIM: N/A
PSM: N/A
The UML 2.x Specification insists that Stereotypes be bound to a
profile.
But in EA, users can freely type-in any name in the "Stereotype" field (
in the "Properties" dialog of a construct ).
Such freely typed-in stereotypes do not belong to any profile.

When exporting to XMI 2.x, we cannot export a stereotype unless we
specify its profile.
So, we create a dummy profile called "thecustomprofile" in the namespace
http://www.sparxsystems.com/profiles/thecustomprofile/1.0 and bind all
the freely typed-in stereotypes to this profile.

For example, refer to the attached Snapshot.png - Class1's stereotype is
"opt" ( I typed-in this in the "Stereotype" field in the "Properties"
dialog of the class ) & Activity1 is a BPMN 2.0 activity.
When exported to XMI 2.x, the stereotype "opt" is linked to
"thecustomprofile" as underlined in green.

NOTE :
XML Namespace is just a method to avoid name conflicts & using the
namespace http://www.sparxsystems.com/profiles/thecustomprofile/1.0
doesn't means that our XMI is OMG in-compliant.
If you want, you can manually change the namespace of the
"thecustomprofile" ( or any other profile used in the XMI file ) from
http://www.sparxsystems.com/profiles/thecustomprofile/1.0 to the desired
namespace ( at the location boxed in brown ).

Revised Text:
PIM: N/A
PSM: N/A
N\A - No Change Necessary

Disposition: Closed No Change

subjectType is not documented on page 3 of the Statement Information Model

Logged: https://github.com/cts2/cts2-specification/issues/92

PIM: Update PIM text
PSM: N/A

11-09-02 CTS2 Code System and Code System Version Catalog Services

On page 16 the attribute of the CodeSystemCatalogVersionEntry the defaultLanguage is defined as the default spoken or written language used in this version. If we look at the cardinality we see it is [0..1]. We believe this should be [0..*]. HL7 CTS2 specifies " The different languages (supportedLanguages) supported by the Code System in this version". For certain official terminology providers the same version can be multilingual. For example the file supplied by ISO ISO-639-2_utf-8.txt is both in English and in French. STS implements the attribute supportedLanguages as a list of languages, which we believe is much more fitted than a defaultLanguage attribute (with only one language). Proposition: Change cardinality.

Logged: https://github.com/cts2/cts2-specification/issues/71

PIM: Updated Diagram (Figure 3.1: Code System Version, Page 19.)
PSM:
Change Location: CodeSystemVersion.xsd
Added a 'supportedLanguage' element to "CodeSystemVersionCatalogEntry."
<xs:element name="supportedLanguage" type="core:LanguageReference" minOccurs="0" maxOccurs="unbounded">
<xs:annotation>
<xs:documentation>all languages recognized by this particular code system version</i></xs:documentation>
</xs:annotation>
</xs:element>

The introductory section about conventions and the like needs to be included in all of the modules. Currently it is just in the Core

Logged: https://github.com/cts2/cts2-specification/issues/93

PIM: Update PIM text
PSM: N/A

restrictToCodeSystem lists InvalidDirectoryType twice in the exception list.

Logged: https://github.com/cts2/cts2-specification/issues/95

PIM:
Update PIM text
PSM:
N/A

The type of knownCodeSystem should be CodeSystemReference instead of CodeSystemVersionReference. This needs to be corrected in both the PIM and the Service schema

Logged: https://github.com/cts2/cts2-specification/issues/94

PIM: Update Diagram (Figure 3.2: Entity Description Query Service)

PSM: In the 'EntityDescriptionReadService' and 'EntityDescriptionQueryService' types, change:
<xs:element name="knownCodeSystem" type="core:CodeSystemVersionReference" minOccurs="0" maxOccurs="unbounded"/>
to
<xs:element name="knownCodeSystem" type="core:CodeSystemReference" minOccurs="0" maxOccurs="unbounded"/>

The stereotype indicates that the operation may change the service state, which is the opposite of the UML isQuery tag. You need to set the isQuery tag to true on all non-delta operations and then include documentation on each operation to repeat what it means because everyone will ignore it otherwise.

Logged: https://github.com/cts2/cts2-specification/issues/111

PIM: Update PIM text
PSM: N/A

MatchValueFormatException was incorrectly typed as "exeption" instead of "exception", which means that it isn't included in the formal PDF documents or Exceptions.xsd. Need to add it to the documentation and the schema.

Logged: https://github.com/cts2/cts2-specification/issues/117

PIM: Update PIM text

PSM: Change the MatchValueFormatException type to 'exception.'

This is related to the string issue pointed out by Manfred. Boolean cannot be defined as a data type, as it is already part of the UML core.

Logged: https://github.com/cts2/cts2-specification/issues/116

PIM: Update PIM text
PSM: N/A

ValidationResponse was missing in final model.

Logged: https://github.com/cts2/cts2-specification/issues/115

PIM: Update PIM text
PSM: N/A

String cannot be defined as a data type, as it is already part of the UML core.

Logged: https://github.com/cts2/cts2-specification/issues/113

PIM: Update PIM text
PSM: N/A

The entity and entitybyuri queries currently return an EntityReference that contains zero or more knownEntityDescriptions. They do this even if there is just one knownEntityDescription. This behavior is not what most clients desire

Would recommend the following:
(a) (re-)add the tag that was present in the LexGrid model that could be used to identify one of the coding systems as the "primary"
(b) State that the default behavior of entity and entitybyuri is to redirect to the only or (when present) tagged entry in the specific codesystem version. The id is that //entity/12345 will redirect to //codesystem/

/version/

/entity/12345 if it is the only describing code system version or its code system (version?) is listed as the primary
(c) add an additional parameter (fwd?) that, when false, says that redirection should not occur.

Logged: https://github.com/cts2/cts2-specification/issues/129

No Data Available

Both the format and language can be supplied as a url parameter or as part of the http header. The current specification doesn't address what to do if both are present.

Recommendation is that the command line takes precedence over Accept and Accept-Language in the header.

Logged: https://github.com/cts2/cts2-specification/issues/130

No Data Available

The change set includes a CLONE type, but we haven't specified a method for asking that a CLONE be performed.

We would anticipate that the method signature would include:
nameOrURI of the the versionable resource to be Cloned
the new version identifier (optional - could be assigned by service or error if it doesn't)
the new version URI (optional)
the change set URI

(we need to check the documentation to see whether there is anything else)

Logged: https://github.com/cts2/cts2-specification/issues/135

No Data Available

The CTS2 specification describes the minimum (and, at the moment, only) content that can be in directories of various types. Implementers are discovering that they need to add information to this to meet special use cases (e.g. ChangeSetURI and ChangeSetNotes for a special value set authoring environment). We need a way to allow directories to be extended for service specific implementations.

Logged: https://github.com/cts2/cts2-specification/issues/137

No Data Available

The resolveAsCompleteSet function allows the client to ask for a ResolvedValueSet (vs. IterableResolvedValueSet). There is currently no way to do this in the REST functions.

Would propose that we add a parameter to queryControl or update the possible values for maxToReturn so a client can indicate that they don't want an iterator, they want the whole thing. We will have to supply a new error message as well - something to the effect of "too much to return all at once"

Logged: https://github.com/cts2/cts2-specification/issues/125

No Data Available

The current tag, "referencelanguage" is a bit unwieldy from the REST perspective. Would recommend adding a synonym, "lang" to address this issue.

Logged: https://github.com/cts2/cts2-specification/issues/127

No Data Available

CodeSystemCatalogEntry.xsd is missing "hasOntologyLanguage" and "includes" elements. These were added to cts2/spec/submission/OMGServerMap/codesystem/CodeSystem.xsd in revision 7641

Logged: https://github.com/cts2/cts2-specification/issues/121

No Data Available

The mapFrom and mapTo elements in Map Entry are currently of type URIAndEntityName, which doesn't allow an explanatory designation to be provided, meaning that it may be necessary to resolve the returned types against a code system. This type should be changed to EntitySynopsis. Changes have been submitted to CTS2 svn repository as change 7853

Logged: https://github.com/cts2/cts2-specification/issues/122

Disposition: See issue 18532 for disposition

While it is possible to construct a URL that requests the resolution of the CURRENT version of a value set, there is no href in the ValueSet schema that allows this query to be performed without knowing URL construction rules. There should be another optional link called "resolution" or something similar where a service can provide an href that allows direct access to the value set resolution.

Logged: https://github.com/cts2/cts2-specification/issues/134

No Data Available

Currently there is no way to resolve a value set definition directly without knowing a specific version - it is first necessary to find the definition via query statements. The REST signatures should include:
//valueset/resolution[?tag=

], which will resolve CURRENT or tag directly. This has already been implemented in the SVS mat implementation.

Logged: https://github.com/cts2/cts2-specification/issues/123

No Data Available

The documentation for //valueset/

/definition/

/resolution found at http://informatics.mayo.edu/svn/trunk/cts2/spec/psm/rest/html/cts2.html#id1171374283352 makes no sense - we need to check the WADL in this area to see what is going on.

Logged: https://github.com/cts2/cts2-specification/issues/124

This is just an WADL -> HTML generation issue – no change needed, documentation is correct in the WADL.
Disposition: Closed, no change

Line 60 in MapVersion.xsd has the wrong type for versiontag. Change:

<xs:element name="versionTag" type="core:MapVersionReference" minOccurs="0" maxOccurs="unbounded">

to

<xs:element name="versionTag" type="core:VersionTagName" minOccurs="0" maxOccurs="unbounded">

Change submitted to svn - cts2/spec/submission/OMGServerMap/mapversion/MapVersion.xsd - revision 7877

Logged: https://github.com/cts2/cts2-specification/issues/133

No Data Available

The REST specification doesn't specify what the service behavior should be on "byuri" type queries. Some implementations use a 303 to get to the base resource while others leave the URI as entered.

Would propose that the specification say that it should always redirect.

Logged: https://github.com/cts2/cts2-specification/issues/128

No Data Available

In the WADL (REST PSM), a Create is done with an HTTP 'PUT' and an update is done with an HTTP 'POST'. This is problematic because a client must have knowledge of the URL structure before doing a create. It will limit implementation as-is because clients cannot be expected to know the URL structure of a resource before it is created. In the case of an update, a 'PUT' is more appropriate because we assume that at that point the client does know the URL of the resource.

Logged: https://github.com/cts2/cts2-specification/issues/84

PIM: N/A
PSM:
Change all creates to an HTTP 'POST' and all updates to an HTTP 'PUT'.

In the StructuralProfile enum, should there be 'SP_STATEMENT' and/or 'SP_MAP_ENTRY' ?

It could be that Statement is intended to be included in the 'Association' profile and MapEntry in the 'MapVersion' profile. If that is the case this issue would be a no-op, or at most a documentation note.

Logged: https://github.com/cts2/cts2-specification/issues/86

PIM: N/A
PSM:
Added two new enum values: 'SP_MAP_ENTRY" and "SP_STATEMENT" to the StructuralProfile enum.
<xs:enumeration value="SP_MAP_ENTRY">
<xs:annotation>
<xs:documentation>The <b>Map_Entry</b> profile represents
individual entries in a
<b>Map_Version</b></xs:documentation>
</xs:annotation>
</xs:enumeration>
<xs:enumeration value="SP_STATEMENT">
<xs:annotation>
<xs:documentation>The <b>Statement</b> profile provides a
bridge between the CTS2 model structure and the
underlying RDF/XML/etc.</xs:documentation>
</xs:annotation>
</xs:enumeration>

Map.xsd MapCatalogEntry currentVersion does not have an XSD type. Should be MapVersionReference...

Logged: https://github.com/cts2/cts2-specification/issues/89

PIM: N/A
PSM:
Changed the type of 'currentVersion' to 'MapVersionReference.'
Original:
<xs:element name="currentVersion" minOccurs="0">
Updated:
<xs:element name="currentVersion" type="core:MapVersionReference" minOccurs="0">

ScopedEntityName.name is set to LocalIdentifier in the XML Schema. The UML specification shows it as "String" and its current setting is preventing us from using SNOMED CT fully specified names and other useful sources.

Logged: https://github.com/cts2/cts2-specification/issues/91

PIM: N/A
PSM:
Changed the 'name' element from 'LocalIdentifier' to 'String.'

The documentation got stripped in the RestResource type in Core.xsd. We propose it read as:

xs:annotation

xs:documentationThe relative URI of the resource with respect to the resourceRoot. As an example,

if the resource URI was "http://informatics.mayo.edu/cts2/rest/codesystems", the resourceURI would

be "codesystems". Fragment and query identifiers should also be included./xs:documentation

xs:appinfoPSM/xs:appinfo

/xs:annotation

/xs:element

xs:annotation

xs:documentationThe paramaters that were used in executing the query. This carries all of the parameters that

are needed to reconstruct the complete query in either a RESTful or procedural environment. The service provider

may or may not include non-CTS2 related parameters such as security tokens, routing requests, etc./xs:documentation

xs:appinfoPSM/xs:appinfo

/xs:annotation

/xs:element

xs:annotation

xs:documentationThe date and time that the resource was accessed./xs:documentation

xs:appinfoPSM/xs:appinfo

/xs:annotation

/xs:element

Logged: https://github.com/cts2/cts2-specification/issues/87

PIM: N/A
PSM:
Added in documentation to the 'RestResource' type as described in the updated xml below.

The current xml schemas in the rest/schema directory present an inconsistent combination of the "Venetian Blind" and "Garden of Eden" schema patterns (http://developers.sun.com/jsenterprise/archive/nb_enterprise_pack/reference/techart/design_patterns.html), where all elements except the elemMsg, elemList and elemDirectory have both complexType and element declarations. The approaches to these two patterns can be quite different in a schema compiler such as pyxb. We propose that all element declarations follow the general pattern:

...

/xs:complexType

For resources that can be document level elements and complex (or simple) for the rest)

Logged: https://github.com/cts2/cts2-specification/issues/88

PIM: N/A
PSM:
Changed any XSD Element in the form of:
<xs:element name='x'>
<xs:complexType>
...
</xs:complexType>
</xs:element>
to:
<xs:element name='x' type = 'x'/>
<xs:complexType name='x'>
...
</xs:complexType>

Rename method 'getKnownCodeSystems' to 'getKnownCodeSystem'.

Rename method 'getKnownCodeSystemVersions' to 'getKnownCodeSystemVersion'.

In method 'restrictToTargetExpression' change the type of param 'target' to EntityExpression

In method 'count' add parameter 'timeout'.

In method 'restrict' change the type of param 'directory' to DirectoryURI

In method 'restrictToTargetLiteral' change the type of param 'target' to String

Logged: https://github.com/cts2/cts2-specification/issues/50

PIM: N/A
PSM:
• Rename method 'getKnownCodeSystems' to 'getKnownCodeSystem'.
• Rename method 'getKnownCodeSystemVersions' to 'getKnownCodeSystemVersion'.
• In method 'restrictToTargetExpression' change the type of param 'target' to EntityExpression
• In method 'count' add parameter 'timeout'.
• In method 'restrict' change the type of param 'directory' to DirectoryURI
• In method 'restrictToTargetLiteral' change the type of param 'target' to String

The QueryControl parameter was omitted from the read and readByURI operations in ConceptDomainBindingService.

Logged: https://github.com/cts2/cts2-specification/issues/81

PIM:
In the ConceptDomainBindingService - methods 'read' and 'readByUri', add a parameter 'queryControl of type 'AssociationDirectoryURI.'
Updated Diagram (Figure 4.1: Concept Domain Binding Read. Concept Domain Binding, Page 20.)

PSM:
Add in the following element to types 'read' and 'readByURI':

<xs:element minOccurs="0" name="queryControl" type="coreService:QueryControl" />

In the AssociationQueryService, the method 'getAllSourceAndTargetEntities' accepts an 'EntityDirectoryURI' as an input. I believe that it should accept an 'AssociationDirectoryURI' (as 'getSourceEntities', 'getTargetEntities', and 'getPredicates' do).

Logged: https://github.com/cts2/cts2-specification/issues/83

PIM: N/A
In the AssociationQueryService - method 'getAllSourceAndTargetEntities', change the parameter 'directory' to type 'AssociationDirectoryURI.'

PSM: N/A

11-09-03 CTS2 Concept Domain and Concept Domain Binding Services

In section 2.2 Concept Domain Catalog Query Service the section goes onto describing Concept Domain Catalog History. Is is possible that the Query service description (resolve and resolveAsList) were missed due to a cut and paste error?

Logged: https://github.com/cts2/cts2-specification/issues/75

PIM: N/A
PSM: N/A
After review, the existing text is correct, and the change should not be applied to the PIM.

11-09-08 Value Set services - The ValueSetCatalogReadService provides direct access to the service map catalog. Typo - Value Set Catalog instead of service map catalog.

Logged: https://github.com/cts2/cts2-specification/issues/78

PIM: Update PIM text
PSM: N/A

In the pdf2 in section 1.1.2.1 Class CodeSystemCatalogEntryDirectory we think this is a typo and it should be CodeSystemDirectory.

Logged: https://github.com/cts2/cts2-specification/issues/69

PIM: N/A
PSM: N/A
After review, the existing text is correct, and the change should not be applied to the PIM.

EntityDescription provides URI's for children, descendants and ancestors, but it only provides parents directly. While this is useful, it means that applications that are traversing graphs have to have two different mechanisms - one for the first three categories and a second for parents. We should add one more attribute, "parents" which allows parents to be accessed by URI as well.

Logged: https://github.com/cts2/cts2-specification/issues/136

No Data Available

Section 2.2.1.1 (Operation resolve), input parameter 'directory' is specified as type CodeSystemCatalogURI. Type should be 'CodeSystemCatalogEntryDirectoryURI'

Section 2.2.1.2 (Operation resolveAsList), input parameter 'directory' is specified as type CodeSystemCatalogURI. Type should be 'CodeSystemCatalogEntryDirectoryURI'

Logged: https://github.com/cts2/cts2-specification/issues/96

This issue does not exist in the "CTS2 - Code System and Code System Version Catalog Services, v1.0" document.
Disposition: Closed, no change

There is no method with a signature: f(conceptDomain, context[0..*], codeSystemVersion[0..*], tag[0..1]) --> ResolvedValueSet

(In that there is no way to say "Give me the resolved value set for this concept domain in this context")

https://github.com/cts2/cts2-specification/issues/149

No Data Available

Issues #141 (http://www.omg.org/issues/cts2-rtf#Issue18470) and #122 (http://www.omg.org/issues/cts2-rtf#Issue18486) add an optional description to valueSetEntry, mapFrom and mapTo. It appears that, with the exception of EntityType and ResourceType, the remainder of the URIAndEntityName references should all be changed to EntitySynopsis, allowing an optional description. Would propose removing EntitySynopsis completely from the model and moving its description property to URIAndEntityName.

Logged: https://github.com/cts2/cts2-specification/issues/143

No Data Available

ResolvedValueSet has 'member' elements while IteratableResolvedValueSet has 'entry' elements.

Recommend moving all elements to 'entry' as that is the pattern for everything else.

Logged: https://github.com/cts2/cts2-specification/issues/147

No Data Available

CTS2Exception in the PIM consists of message and severity. The XML schema has an extra element that makes no sense - ExceptionType. This appears to be an artifact that was accidentally left in the UML model, but is never used in the spec itself.

This should be removed from both places - the UML and the exception schema

Logged: https://github.com/cts2/cts2-specification/issues/148

No Data Available

In the description of the Code System Catalog Entry the identification is done via the Code System name: “codeSystemName - the local identifier that uniquely identifies the code system within the context of the implementing service. Note that the about URI is the globally unique identifier”.

The HL7 culture is used to manage messages and documents via OIDs which. An optional attribute: CodeSystemOID is needed. The issue here is not turning an OID into a URI but having the possibility to have SIMULTANEOUSLY the URI and OID present (an additional attribute aside from about). In all IHE domains we use OIDs to identify objects. There is no strong consensus and a mechanism of sharing URI so that complete interoperability can be achieved. In this transition context we need a means to assure this transition while assuring interoperability. https://github.com/cts2/cts2-specification/issues/144

No Data Available

In cases where the associationID is supplied, it is the ID that gets you from the directory contents to the actual association.

This change has been added to revision 7733 in cts2/spec/submission/OMGServerMap/association/Association.xsd on 10/4/2012

Logged: https://github.com/cts2/cts2-specification/issues/118

No Data Available

Generating associationID's when none exist just produces noise. The associationID parameter should made optional in the PIM where the service doesn't support AssociationRead. This needs to be changed in the schema AND the spec.

Schema has been updated in revision 7752 in cts2/spec/submission/OMGServerMap/association/Association.xsd

Logged: https://github.com/cts2/cts2-specification/issues/119

No Data Available

The PropertyReference class in Filter, and corresponding elements in the query signatures doesn't specify exactly how one should create a referenceTarget for references of type Attribute. As an example, how would one go about specifying the uri attribute in the source component of a sourceAndRole element? The behavior is underspecified if the reference not to a leaf (e.g. "sourceAndRole") Recommend it should specify match anything except href.

If it is going to require URIAndEntityName (vs. 'or'), we need to clearly state what URI is used in the CTS2 spec. Otherwise we need to change the signature to allow just a name (preferred).

Logged: https://github.com/cts2/cts2-specification/issues/151

No Data Available

The association graph structure is considerably easier to use if has a dept indicator. While this could be computed, it is much easier to traverse if explicitly present.

This change has been added to Association.xsd in cts2/spec/submission/OMGServerMap/association

Still needs to be documented and added to the spec itself

Logged: https://github.com/cts2/cts2-specification/issues/120

No Data Available

Section 2.2.1.1 (Operation resolve), input parameter 'directory' is specified as type ConceptDomainDirectoryURI. Type should be 'ConceptDomainCatalogEntryDirectoryURI'

Logged: https://github.com/cts2/cts2-specification/issues/97

This issue does not exist in the "CTS2 - Concept Domain and Concept Domain Binding Services, v1.0" document.
Disposition: Closed, no change

URIAndEntityName does not represent what is in the UML. The UML says that the only thing that is required is the uri – the name and href are optional. The Schema says that the namespace and name is required.

Logged: https://github.com/cts2/cts2-specification/issues/98

No Data Available

In method 'putChangeSet' add param 'errorResponse'

In method 'validateChangeSet' add param 'validationLevel'

In method 'updateChangeSetMetadata' add param 'officialEffectiveDate'

In method 'updateChangeableMetadata' remove params 'target' and 'owner' and add param 'entryID'

Removed methods 'createAssociationsFromExpression' and 'createAssociationFromExpression'

Added method 'addAssociation

Added params 'subject', 'predicate', 'target', 'ecternalStatementId' to method 'updateAssociation;

Logged: https://github.com/cts2/cts2-specification/issues/54

PIM: N/A
PSM:
• In method 'putChangeSet' add param 'errorResponse'
• In method 'validateChangeSet' add param 'validationLevel'
• In method 'updateChangeSetMetadata' add param 'officialEffectiveDate'
• In method 'updateChangeableMetadata' remove params 'target' and 'owner' and add param 'entryID'
• Removed methods 'createAssociationsFromExpression' and 'createAssociationFromExpression'
• Added method 'addAssociation

In method 'count' add parameter 'timeout'

For methods 'getLatestChangeFor', 'getChangeHistoryFor', and 'getEarliestChangeFor' change param 'assocation' type to URI

Add methods 'getEarliestServiceChange', 'getLatestServiceChange', and 'getLatestServiceChange'

Logged: https://github.com/cts2/cts2-specification/issues/53

PIM: N/A
PSM:
• In method 'count' add parameter 'timeout'
• For methods 'getLatestChangeFor', 'getChangeHistoryFor', and 'getEarliestChangeFor' change param 'assocation' type to URI
• Added methods 'getEarliestServiceChange', 'getLatestServiceChange', and 'getServiceHistoryFor'

In method 'readByExternalStatementId' remove param 'assertingCodeSystemVersion' and replace with 'scopingNamespace'.

In method 'existsByExternalStatementId' remove param 'assertingCodeSystemVersion' and replace with 'scopingNamespace'.

In method 'read' change type of 'associationId' param to URI

In method 'exists' change type of 'associationId' param to URI

Logged: https://github.com/cts2/cts2-specification/issues/52

PIM: N/A
PSM:
• In method 'readByExternalStatementId' remove param 'assertingCodeSystemVersion' and replace with 'scopingNamespace'.
• In method 'existsByExternalStatementId' remove param 'assertingCodeSystemVersion' and replace with 'scopingNamespace'.
• In method 'read' change type of 'associationId' param to URI
• In method 'exists' change type of 'associationId' param to URI

Rename method 'getKnownCodeSystems' to 'getKnownCodeSystem'.

Rename method 'getKnownCodeSystemVersions' to 'getKnownCodeSystemVersion'.

Rename method 'getSupportedVersionTags' to 'getSupportedVersionTag'.

In method 'restrictToTargetExpression' change the type of param 'target' to EntityExpression

In method 'count' add parameter 'timeout'.

In method 'getAllSourceAndTargetEntities' change the type of param 'directory' to EntityDirectoryURI

In method 'restrict' change the type of param 'directory' to DirectoryURI

In method 'restrictToTargetLiteral' change the type of param 'target' to String

Logged: https://github.com/cts2/cts2-specification/issues/51

PIM: N/A
PSM:
• Rename method 'getKnownCodeSystems' to 'getKnownCodeSystem'.
• Rename method 'getKnownCodeSystemVersions' to 'getKnownCodeSystemVersion'.
• In method 'restrictToTargetExpression' change the type of param 'target' to EntityExpression
• In method 'count' add parameter 'timeout'.
• In method 'restrict' change the type of param 'directory' to DirectoryURI
• In method 'restrictToTargetLiteral' change the type of param 'target' to String

In method 'readChangeSet' add param 'queryControl;

In method 'updateChangeSetMetadata added param 'officialEfectiveDate;

In method putChangeSet change return type to ProcessStatus

Logged: https://github.com/cts2/cts2-specification/issues/63

PIM: N/A
PSM:
• In method 'readChangeSet' add param 'queryControl'
• In method 'updateChangeSetMetadata added param 'officialEffectiveDate'
• In method putChangeSet change return type to ProcessStatus'

In 'count' method added 'timeout' param.

Renamed method 'restrictToCodeSystemVersions' to 'restrictToCodeSystemVersion'

Added method 'restrictToEntities', 'isEntityInSet', and 'intersectEntityList'

Renamed method 'restrictToCodeSystems' to 'restrictToCodeSystem'

Logged: https://github.com/cts2/cts2-specification/issues/62

PIM: N/A
PSM:
• In 'count' method added 'timeout' param.
• Renamed method 'restrictToCodeSystemVersions' to 'restrictToCodeSystemVersion'
• Added method 'restrictToEntities', 'isEntityInSet', and 'intersectEntityList'
• Renamed method 'restrictToCodeSystems' to 'restrictToCodeSystem'

Rename method 'getKnownCodeSystems' to 'getKnownCodeSystem'.

Rename method 'getKnownCodeSystemVersions' to 'getKnownCodeSystemVersion'.

Rename method 'getSupportedVersionTags' to 'getSupportedVersionTag'.

Logged: https://github.com/cts2/cts2-specification/issues/49

PIM: N/A
PSM:
• Rename method 'getKnownCodeSystems' to 'getKnownCodeSystem'.
• Rename method 'getKnownCodeSystemVersions' to 'getKnownCodeSystemVersion'.
• Rename method 'getSupportedVersionTags' to 'getSupportedVersionTag'

In method 'count' add param 'timeout'.

Rename 'getLatestChange' to 'getLastChange'.

In method 'getChangeHistoryFor' rename param 'codeSystem' to 'codeSystemVersion'

In method 'getEarliestChangeFor' rename param 'codeSystem' to 'codeSystemVersion'

Logged: https://github.com/cts2/cts2-specification/issues/48

PIM: N/A
PSM:
• In 'count' method added 'timeout' param.
• Rename 'getLatestChange' to 'getLastChange'.
• In method 'getChangeHistoryFor' rename param 'codeSystem' to 'codeSystemVersion'
• In method 'getEarliestChangeFor' rename param 'codeSystem' to 'codeSystemVersion'

In method 'putChangeSet' added param 'errorResponse'

In method 'updateChangeSetMetadata' added param 'officialEffectiveDate'

In method 'readChangeSet' added param 'queryControl'

In method 'updateConceptDomainBinding' renamed param 'conceptDomain' to conceptDomainBinding'

In method 'validateChangeSet' added param 'validationLevel'

In method 'updateChangeableMetadata' removed 'target' and 'owner' params and added 'entryID' param.

In method 'newProperty' removed param 'entity' and added param 'predicate'

Logged: https://github.com/cts2/cts2-specification/issues/58

PIM: N/A
PSM:
• In method 'putChangeSet' add param 'errorResponse'
• In method 'validateChangeSet' add param 'validationLevel'
• In method 'updateChangeSetMetadata' add param 'officialEffectiveDate'
• In method 'readChangeSet' added param 'queryControl'
• In method 'updateChangeableMetadata' remove params 'target' and 'owner' and add param 'entryID'
• In method 'updateConceptDomainBinding' renamed param 'conceptDomain' to conceptDomainBinding'
• In method 'newProperty' removed param 'entity' and added param 'predicate'

In method 'count' add a 'timeout' param.

Logged: https://github.com/cts2/cts2-specification/issues/57

PIM: N/A
PSM: In 'count' method added 'timeout' param.

Changed all URI param types from String to LocalURI or DocumentURI

Logged: https://github.com/cts2/cts2-specification/issues/56

PIM: N/A
PSM: Changed all URI param types from String to LocalURI or DocumentURI

Renamed method 'getKnownCodeSystems' to 'getKnownCodeSystemVersion'

Removed method 'getSupportedVersionTags'

Logged: https://github.com/cts2/cts2-specification/issues/61

PIM: N/A
PSM: Renamed method 'getKnownCodeSystems' to 'getKnownCodeSystemVersion'

In method 'count' added a 'timeout' param

In method 'readChangeSet' renamed param 'URI' to 'changeSetURI'

Logged: https://github.com/cts2/cts2-specification/issues/60

PIM: N/A
PSM:
• In 'count' method added 'timeout' param.
• In method 'readChangeSet' renamed param 'URI' to 'changeSetURI'

Removed method 'getSupportedVersionTags' and 'fromEntityDirectory'

In method 'toAssociationFormat' changed type of param 'codeSystemVersion' to 'CodeSystemVersionReference'

Logged: https://github.com/cts2/cts2-specification/issues/55

PIM: N/A
PSM:
Removed method 'getSupportedVersionTags' and 'fromEntityDirectory'
• Reason: Refactored into BaseService

In method 'toAssociationFormat' changed type of param 'codeSystemVersion' to 'CodeSystemVersionReference'
• Reason: Typo

In method 'count' added a 'timeout' param

Logged: https://github.com/cts2/cts2-specification/issues/59

PIM: N/A
PSM: In 'count' method added 'timeout' param.

Appendix 10 of the OMG "Hitchhiker's Guide" (http://www.omg.org/cgi-bin/doc?hh) specifies a directory structure for organizing submission documents. While older specifications were organized as "spec.omg.org/...", the current direction is that the documents should be organized in "www.omg.org/spec//, where version would be "Beta2", "1.0" for the base spec and "yyyymmmm" for accompanying files.

The OMG AB believes that this set of requirements would imply that the CTS2 URIs should change from "http://spec.omg.org/cts2/1.0/" to "http://www.omg.org/spec/cts2/1.0/".

Logged: https://github.com/cts2/cts2-specification/issues/90

Resolution (PIM)
N/A

Resolution (PSM)

In each of the following files, all references to: "http://schema.omg.org/spec/CTS2/1.0"
are being changed to: "http://www.omg.org/spec/CTS2/1.1".

Change Location

AdvancedAssociationQueryService.wsdl
AssociationHistoryService.wsdl
AssociationMaintenanceService.wsdl
AssociationQueryService.wsdl
AssociationReadService.wsdl
AssociationTransformService.wsdl
BaseExportService.wsdl
BaseImportService.wsdl
CodeSystemCatalogHistoryService.wsdl
CodeSystemCatalogMaintenanceService.wsdl
CodeSystemCatalogQueryService.wsdl
CodeSystemCatalogReadService.wsdl
CodeSystemVersionCatalogHistoryService.wsdl
CodeSystemVersionCatalogMaintenanceService.wsdl
CodeSystemVersionCatalogQueryService.wsdl
CodeSystemVersionCatalogReadService.wsdl
ConceptDomainBindingMaintenanceService.wsdl
ConceptDomainBindingQueryService.wsdl
ConceptDomainBindingReadService.wsdl
ConceptDomainCatalogHistoryService.wsdl
ConceptDomainCatalogMaintenanceService.wsdl
ConceptDomainCatalogQueryService.wsdl
ConceptDomainCatalogReadService.wsdl
EntityDescriptionHistoryService.wsdl
EntityDescriptionMaintenanceService.wsdl
EntityDescriptionQueryService.wsdl
EntityDescriptionReadService.wsdl
EntityDescriptionTransformService.wsdl
MapCatalogHistoryService.wsdl
MapCatalogMaintenanceService.wsdl
MapCatalogQueryService.wsdl
MapCatalogReadService.wsdl
MapEntryHistoryService.wsdl
MapEntryMaintenanceService.wsdl
MapEntryQueryService.wsdl
MapEntryReadService.wsdl
MapResolutionService.wsdl
MapVersionHistoryService.wsdl
MapVersionMaintenanceService.wsdl
MapVersionQueryService.wsdl
MapVersionReadService.wsdl
ReasoningService.wsdl
ResolvedValueSetLoader.wsdl
ResolvedValueSetQueryService.wsdl
ResolvedValueSetResolution.wsdl
StatementHistoryService.wsdl
StatementQueryService.wsdl
StatementReadService.wsdl
UpdateService.wsdl
ValueSetCatalogHistoryService.wsdl
ValueSetCatalogMaintenanceService.wsdl
ValueSetCatalogQueryService.wsdl
ValueSetCatalogReadService.wsdl
ValueSetDefinitionHistoryService.wsdl
ValueSetDefinitionMaintenanceService.wsdl
ValueSetDefinitionQueryService.wsdl
ValueSetDefinitionReadService.wsdl
ValueSetDefinitionResolution.wsdl

Change Description

Changes to machine readable files are easily identified by Git using the color red to indicate “deletion” and green to indicate “addition.” Furthermore, the ‘-‘ minus sign is also displayed to indicate a deletion, and a “+” plus sign is displayed to indicate an addition.

View Changes: https://github.com/cts2/cts2-specification/commit/890558063ee42dd3a21419f942abe16f0a634677

Due to number of changes, please review the PDF.
http://informatics.mayo.edu/svn/trunk/cts2/spec/submission/RTF_1.1/RTF_Issues/CTS2_RTF_1.1_17318.pdf

On page 39 of Core the description of the documentURI attribute in ResourceVersionDescription stops in mid sentence with a "100".

Logged: https://github.com/cts2/cts2-specification/issues/139

Resolution (PIM)
Location 1
Document "CTS2 - Core Model Elements, v1.0"
Section 2.7.1.5
Page 39
Change Description 1
Change made to Attributes section.
Old Text:
documentURI - a URI that identifies the specific version, language, and notation of the about resource. This URI needs to be constructed in such a way that, if necessary, it will be possible to differentiate resource versions that were loaded from different document syntaxes. As an example, if an image of the wine ontology was loaded from a resource that was in Manchester Syntax, it should be given a different URI than the image loaded from the RDF/XML syntax. The reasoning behind this is, even in cases where different syntaxes are 100.
New Text:
documentURI - a URI that identifies the specific version, language and notation of the about resource. This URI needs to be constructed in such a way that, if necessary, it will be possible to differentiate resource versions that were loaded from different document syntaxes. As an example, if an image of a the wine ontology was loaded from a resource that was in Manchester Syntax, it should be given a different URI than the image loaded from the RDF/XML syntax. The reasoning behind this is, even in cases where different syntaxes are 100% compatible the transformation into the CTS2 model may not be identical.
Resolution (PSM)
Change Location
Core.xsd
Change Description
Changes to machine readable files are easily identified by Git using the color red to indicate “deletion” and green to indicate “addition.” Furthermore, the ‘-‘ minus sign is also displayed to indicate a deletion, and a “+” plus sign is displayed to indicate an addition.
View changes: https://github.com/cts2/cts2-specification/commit/138ee6180cb52fa1176ac0f3bbfd93b54de34205

The current description of entityType in section 2.1.1.1 of the Entity Description Services (page 6) reads:
entityType - the set of type(s) which the entityReference is an instance of. Because this is a terminology service, entityType must include one of owl:class, owl:individual, rdf:predicate, or skos:concept, although it may carry many other types as well.

This is incorrect - it should read:
"... must include one of owl:Class, owl:Individual, rdf:Property or skos:Concept"

Note that this may potentially effect some implementations that have either transcribed the information literally or have used "rdf:predicate" instead of "ref:Property"

Logged: https://github.com/cts2/cts2-specification/issues/142

At the moment, SourceAndNotation is a required field. In many situations there is nothing of value that can be supplied here - it should be made optional.

Logged: https://github.com/cts2/cts2-specification/issues/140

see pages 35 - 37 of prc/2013-06-02 for details

AssociatedEntitiesReference.referencedEntity and SpecificEntityList.referencedEntity are currently of type URIAndEntityName. This does not provide any place to include a designation or description of the entity. The type should be changed to EntitySynopsis

Logged: https://github.com/cts2/cts2-specification/issues/141

See issue 18532 for disposition

The DocumentURI was intended to differentiate situations where there were potentially multiple sources of the same version of a resource (e.g. SNOMED CT 20120731 from RF1, RF2, RRF or Owl). This is the exception, rather than the rule, and the DocumentURI field should be made optional for clarity.

Logged: https://github.com/cts2/cts2-specification/issues/138

Resolution (PIM)
Change Location 1
Document "CTS2 - Core Model Elements, v1.0"
Section 2.7.2
Page 40
Figure 2.17
Change Description 1
Updated diagram in Figure 2.17
Old Diagram:

SortCriteria contains PropertyReference, which implies that the user needs to know the EntityName AND URI of the Property to sort. We want all user input to be Name OR URI. There needs to be a flavor of SortCriteria that doesn't require the user to know the Name AND URI of the Property to sort.

Logged: https://github.com/cts2/cts2-specification/issues/5

PIM: N/A
PSM:
In the type 'SortCriterion', the element 'sortElement' was changed from:
type="core:PropertyReference"
to
type="PropertyNameOrURI"

'applicableContext' cardinality in ConceptDomainBinding (XSD) needs to change to 0..1 to align with the PIM.

Logged: https://github.com/cts2/cts2-specification/issues/4

PIM: N/A
PSM:
Changed the 'applicableContext' attribute of ConceptDomainBinding from:
minOccurs="0" maxOccurs="unbounded"
to:
minOccurs="0" maxOccurs="1"

'bindingQualifier' in ConceptDomainBinding (XSD) should be moved to an Element of type BindingQualifierReference and be 0..1.

Logged: https://github.com/cts2/cts2-specification/issues/3

PIM: N/A
PSM:
• Attribute 'bindingQualifier' in ConceptDomainBinding (XSD) was removed.
• Element of type BindingQualifierReference with cardinality 0..1 was added.

'boundValueSet' cardinality in ConceptDomainBindingDirectoryEntry (XSD) needs to change from 0..* to to 1..1

Logged: https://github.com/cts2/cts2-specification/issues/2

PIM: N/A
PSM:
Change cardinality of ConceptDomainBindingDirectoryEntry from:
minOccurs="0" maxOccurs="unbounded"
to the XML default, which is:
minOccurs="1" maxOccurs="1"

Add effectiveDate, changeNotes, changeSource parameters, all optional. Used to update ChangeDescription if supported by the service

Logged: https://github.com/cts2/cts2-specification/issues/11

PIM: Updated Diagram (Figure 3.7: Maintenace Service. Core, Page 56.)
PSM:
Add in the following elements to the type 'UpdateChangeableMetadataRequest':

<xs:element name="updatedEffectiveDate" minOccurs="0">
<xs:complexType>
<xs:sequence>
<xs:element name="effectiveDate"
type="core:DateAndTime" minOccurs="0"/>
</xs:sequence>
</xs:complexType>
</xs:element>
<xs:element name="updatedChangeNotes" minOccurs="0">
<xs:complexType>
<xs:sequence>
<xs:element name="changeNotes" type="core:OpaqueData"
minOccurs="0"/>
</xs:sequence>
</xs:complexType>
</xs:element>
<xs:element name="updatedChangeSource" minOccurs="0">
<xs:complexType>
<xs:sequence>
<xs:element name="changeSource"
type="core:SourceReference" minOccurs="0"/>
</xs:sequence>
</xs:complexType>
</xs:element>

Changeable/ChangeDescription typo

PIM: Update PIM text
PSM: N/A

FilterComponent is a PropertyReference and contains a MatchAlgorithm reference, which implies that the user needs to know the Name AND URI of both of these. We want all user input to be Name OR URI. There needs to be a flavor of FilterComponent that doesn't require the user to know the Name AND URI of these.

Logged: https://github.com/cts2/cts2-specification/issues/6

PIM: N/A
PSM:
A new FilterComponent type was introduced to extend from "PropertyNameOrURI" instead of "PropertyReference". This type is to be used for all client interaction into the interfaces on the PSM level.

Target cardinalityTarget should be 1..* to allow things like unionof(a,b,c...). Need to change spec and schema

PIM:
Updated Diagram (Figure 1.1: Statement Model. Statement, Page 2.)
PSM:
Change the 'target' element in the type 'AnonymousStatement' from
<xs:element name="target" type="StatementTarget" minOccurs="1" maxOccurs="1">
to
<xs:element name="target" type="StatementTarget" minOccurs="1" maxOccurs="unbounded">

ChangeType, committed, containingChangeSet, prevChangeSet, changeDate and clonedResource should be ReadOnly

Logged: https://github.com/cts2/cts2-specification/issues/9

PIM:
Updated Diagram (Figure 2.12: CTS2 Change Model. Core, Page 30.)
PSM: N/A

StatmentQualifier -> statementQualifier

Logged: https://github.com/cts2/cts2-specification/issues/8

PIM:
Update PIM text
Updated Figure 1.1: Statement Model. Statement Information Model, Page 2.

PSM: N/A

In each Query Service, it would be helpful for the user to be able to select certain attributes of the resource to be included (or excluded). For instance, a user may only be interested in the Definitions, or a given named property. Right now, for the Query Service, the user is limited to either 1) the directory entry, or 2) the list representation, which is the entire resource. It would be helpful to have the option of something in between.

Logged: https://github.com/cts2/cts2-specification/issues/155

See OMG Issue 18474 (#137) for disposition.

Disposition: See issue 18474 for disposition

Currently, to get an association graph in REST, the graph is retrieved by:

/codesystem/cs/version/1.0/graph

It would be more correct to be like:

/codesystem/cs/version/1.0/associations/graph

to take into account the 'graph' taking in the association directory as an input. Right now, the 'graph' resource is used in place of the 'associations' resource, but this makes it very hard to do queries such as:

/codesystem/cs/version/1.0/entity/C12345/children/graph

Logged: https://github.com/cts2/cts2-specification/issues/152

No Data Available

In the schema: http://www.omg.org/spec/cts2/201206/mapversion/MapEntryServices.xsd, the types 'MapTargetList' and 'MapTargetListList' need corresponding Message elements, such as 'MapTargetListMsg' and 'MapTargetListListMsg.'

The WADL would need to be updated accordingly to represent the new return types.

Logged: https://github.com/cts2/cts2-specification/issues/154

No Data Available

The UML model in figure 4.4 of the ValueSet document lists the cardinality of includesResolvedValueSet as [0..1]. It should be [0..*].

https://github.com/cts2/cts2-specification/issues/150

No Data Available

ValueSetDefinitionResolution 'resolve' method has incorrect return type. It should be IterableResolvedValueSet.

6.1.1.1 Operation: resolve

Resolve the value set definition against the supplied code system versions and/or version tags.

....

Return Type: ResolvedValueSetDirectory

should be:

6.1.1.1 Operation: resolve

Resolve the value set definition against the supplied code system versions and/or version tags.

....

Return Type: IterableResolvedValueSet

Logged: https://github.com/cts2/cts2-specification/issues/159

No Data Available

The specification states that derivation can be ASSERTED, INFERRED or omitted, meaning that the derivation is unknown. The UML diagram shows it as required, which is wrong. The XML Schema shows it with a default of ASSERTED, which also needs to be removed.

Logged: https://github.com/cts2/cts2-specification/issues/157

see pages 258 - 260 of ptc/2013-06-02 for details

In the WADL, two MapEntry URLS were omitted:
map/

/version/

/entrybyuri/resolution?uri=.

Logged: https://github.com/cts2/cts2-specification/issues/153

No Data Available

The derivation attribute (INFERRED/ASSERTED) needs to be visible in an association directory, as it helps consumers understand the abstract structure.

Logged: https://github.com/cts2/cts2-specification/issues/156

No Data Available

Type of maxtoreturn is string in the WADL definitions. It should be NaturalNumber (or equiv)

Logged: https://github.com/cts2/cts2-specification/issues/158

No Data Available

in ValuseSetDefinition.xsd, SpecificEntityList is defined as an extension of ValueSetDefinitionEntry. This is not correct - it should be a stand alone type.

Logged: https://github.com/cts2/cts2-specification/issues/24

PIM: N/A
PSM:
Remove the 'ValueSetDefinitionEntry' extension from the complex type 'SpecificEntityList'.

Core.xsd defines Note with both assertingInCodeSystemVersion and externalId as attributes, making the type of assertingCodeSystemVersion "CodeSystemVersionName". Entity.xsd defines Designation them both as elements, with the type of assertingCodeSystemVersion set to "CodeSystemVersionReference".

Recommend that the Note pattern be used in Designation as well

Logged: https://github.com/cts2/cts2-specification/issues/23

PIM: N/A
PSM:
Apply the element/attribute convention of the type 'Note' to the type 'Designation'.

The XML Schema uses xsd:restriction to constrain the type of URI that can be used in EntityDescription. It accidentally factored out the name and description attributes, however. This change has been submitted to version control

Logged: https://github.com/cts2/cts2-specification/issues/25

PIM: N/A
PSM:
A sequence was inserted include the name and description attributes (addtion shown below):
<xs:sequence>
<xs:element name="name" type="ScopedEntityName" minOccurs="0">
<xs:annotation>
<xs:documentation>the namespace and name by which this
entity is known within the context of the service
implementation</xs:documentation>
</xs:annotation>
</xs:element>
<xs:element name="knownEntityDescription"
type="DescriptionInCodeSystem" minOccurs="0"
maxOccurs="unbounded">
<xs:annotation>
<xs:documentation>a reference to a version of a code
system that makes one or more assertions about the
referenced entity. Note that only one version of a
given code system is allowed in the
<i>describingCodeSystem</i> list. Unless specified
otherwise in a specific call, the code system version
with the tag "CURRENT" must be
used.</xs:documentation>
</xs:annotation>
</xs:element>
</xs:sequence>

Should be 0..*

Logged: https://github.com/cts2/cts2-specification/issues/15

PIM:
Updated Diagram (Figure 2.4 :Code System Catalog Maintenance. Code System Catalog, Page 15.)

PSM:
Update the ''UpdateCodeSystemCatalogEntry' type with a new element to allow for updates of 'usedOntologyEngineeringTool'.

Add in an element to 'UpdateCodeSystemCatalogEntry' to allow for updates of 'usedOntologyEngineeringTool'

<xs:element name="updatedUsedOntologyEngineeringTools"
minOccurs="0">
<xs:complexType>
<xs:sequence>
<xs:element name="usedOntologyEngineeringTool"
type="core:OntologyEngineeringToolReference"
minOccurs="0" maxOccurs="unbounded"/>
</xs:sequence>
</xs:complexType>
</xs:element>

CTS2: Core spec p57 typo
Createchangeset condition 8
https://github.com/cts2/cts2-specification/issues/12

Core spec p62 typo
AbstractResourc.... Goes off page
Logged: https://github.com/cts2/cts2-specification/issues/13

CTS2: Core spec p75 typo
ExportStatus missing documentation
Logged: https://github.com/cts2/cts2-specification/issues/14

PIM:
Update PIM text
PSM:
N/A

The documentation for ProfileElement in CoreService.xsd is not correct. Need to chase this back to its source and fix it.

Logged: https://github.com/cts2/cts2-specification/issues/27

PIM:
N/A

PSM:
Add the following documentation to the 'ProfileElement' type:

ProfileElement appears in service implementations, once per structural profile that is supported by the implementation instance. Each occurrence records the set of functional profiles that are supported for the specific structural profile