<< Back to previous view

[CCPP-109] What URI does getURI() return
Created: 22/Jun/10  Updated: 14/Oct/10

Status: Closed
Project: OASIS SCA C-CPP TC
Component/s: C++ specification
Affects Version/s: Version 1.1
Fix Version/s: Version 1.1

Type: Bug Priority: Major
Reporter: Andrew Borley Assigned To: Bryan Aupperle
Resolution: Fixed Votes: 0


 Description   
Target: C++ Specification CD05

Description: The description of the getURI() member function of ComponentContext states that the method returns the absolute URI of the component.. It is unclear what the absolute URI of a component is. At run time a component has a structural URI as defined in section 5.8 of the Assembly spec. The structural URI of a component is relative to the domain., so an absolute URI could be formed by concatenating the domain URI and the structural URI. However, there is no standard way to define a domain URI and it is unclear if including the domain URI adds any additional value.

Proposal: replace "absolute" with "structural" in the description of getURI().

Raised to the OASIS Service Component Architecture / C and C++ (SCA-C-C++) TC in the e-mail at http://lists.oasis-open.org/archives/sca-c-cpp/201006/msg00010.html


 Comments   
Comment by Andrew Borley [ 15/Jul/10 10:07 AM ]
Issue opened in SCA C and C++ Telcon Thursday, 15 July 2010.
See minutes at http://www.oasis-open.org/committees/event.php?event_id=28034
Comment by Andrew Borley [ 15/Jul/10 10:20 AM ]
Issue resolved in SCA C and C++ Telcon Thursday, 15 July 2010.
See minutes at http://www.oasis-open.org/committees/event.php?event_id=28034
Comment by Bryan Aupperle [ 14/Oct/10 10:50 AM ]
Included in CD06 (approved 14 Oct 2010).




[CCPP-108] Add C++ test case for getURI()
Created: 18/Jun/10  Updated: 14/Oct/10

Status: Closed
Project: OASIS SCA C-CPP TC
Component/s: C++ Public Review
Affects Version/s: Version 1.1
Fix Version/s: Version 1.1

Type: Bug Priority: Major
Reporter: Andrew Borley Assigned To: Bryan Aupperle
Resolution: Fixed Votes: 0


 Description   
Target: C++ test cases CD01

Description: There is currently no test case for ComponentContext::getURI();

Proposal: Add CPP_6007_TestCase which uses Service1Impl22 which invokes getURI(). and returns the result back to the test client..
Updated TestCase document:
Artifact details found here: http://tools.oasis-open.org/version-control/browse/wsvn/sca-c-cpp/TestCases/cppcni/src/main/?rev=226&sc=1

Raised to the OASIS Service Component Architecture / C and C++ (SCA-C-C++) TC in the e-mail at http://lists.oasis-open.org/archives/sca-c-cpp/201006/msg00008.html

 Comments   
Comment by Andrew Borley [ 15/Jul/10 10:06 AM ]
Issue opened in SCA C and C++ Telcon Thursday, 15 July 2010.
See minutes at http://www.oasis-open.org/committees/event.php?event_id=28034
Comment by Andrew Borley [ 15/Jul/10 10:07 AM ]
Issue resolved in SCA C and C++ Telcon Thursday, 15 July 2010.
See minutes at http://www.oasis-open.org/committees/event.php?event_id=28034
Comment by Bryan Aupperle [ 14/Oct/10 10:50 AM ]
Included in CD02 (approved 14 Oct 2010).




[CCPP-107] Restriction base types have incorrect namespace
Created: 05/May/10  Updated: 02/Jun/10

Status: Closed
Project: OASIS SCA C-CPP TC
Component/s: C test suite
Affects Version/s: Version 1.1
Fix Version/s: Version 1.1

Type: Bug Priority: Major
Reporter: Bryan Aupperle Assigned To: Bryan Aupperle
Resolution: Fixed Votes: 0


 Description   
Target: Test_Types.xsd in the C test suite

Description: Test_Types.xsd defines several types of bounded lengths. These types are all restrictions of standard XSD types. The target namespace for the schema is the OASIS scatest namespace to be consistent with the namespace for the comosite and componentType documents in the test suite. But the base types in the restrictions in the schema are not namespace qualified and thus the base types are not in the correct namespace. For example:
    <simpleType name="boundedString50">
        <restriction base="string">
            <maxLength value="49"/>
        </restriction>
    </simpleType>

Proposal:
Define the standard schema namespace:
    xmlns:xsd="http://www.w3.org/2001/XMLSchema"

and update the definitions to use the xsd prefix like this:
    <simpleType name="boundedString50">
        <restriction base="xsd:string">
            <maxLength value="49"/>
        </restriction>
    </simpleType>

Raised to the OASIS Service Component Architecture / C and C++ (SCA-C-C++) TC in the e-mail at http://lists.oasis-open.org/archives/sca-c-cpp/201005/msg00028.html

 Comments   
Comment by Andrew Borley [ 06/May/10 10:04 AM ]
Issue opened in SCA C and C++ Telcon Thursday, 6 May 2010.
See minutes at http://www.oasis-open.org/committees/event.php?event_id=26115
Comment by Andrew Borley [ 06/May/10 10:05 AM ]
Issue resolved in SCA C and C++ Telcon Thursday, 6 May 2010.
See minutes at http://www.oasis-open.org/committees/event.php?event_id=26115
Comment by Bryan Aupperle [ 02/Jun/10 09:26 AM ]
Fix included in C Test Suite CD01 (Approved 29 Apr. 2010, this fix applied before publication)




[CCPP-106] C++ mapping of multi-valued parameters
Created: 11/Mar/10  Updated: 14/Oct/10

Status: Closed
Project: OASIS SCA C-CPP TC
Component/s: C++ specification
Affects Version/s: Version 1.1
Fix Version/s: Version 1.1

Type: Bug Priority: Major
Reporter: Andrew Borley Assigned To: Bryan Aupperle
Resolution: Fixed Votes: 0


 Description   
Target C++ C&I Spec (CD 05)

Description: Section 9.3 defines the data mapping between C++ and WSDL/XML. The mapping is defined for simple types and complex types but there is no definition for multi-value elements (C++ arrays, list, vectors etc. and XML elements with maxOccurs > 1). If the XML element is contained in a complex type, but not directly mapped to a function parameter/return type, the normal SDO mapping rules apply, the resulting property has isMany=true. However, if the element is defining a function parameter/return type, there is no containing DataObject. and the mapping is not defined.

For example:
<wsdl:definitions name="Service4Service"
        targetNamespace="http://test.sca.oasisopen.org/" xmlns:tns="http://test.sca.oasisopen.org/"
        xmlns:wsdl="http://schemas.xmlsoap.org/wsdl/" xmlns:xs="http://www.w3.org/2001/XMLSchema"
        xmlns:SOAP="http://schemas.xmlsoap.org/wsdl/soap/" xmlns:SOAP11="http://schemas.xmlsoap.org/wsdl/soap/">
        <wsdl:types>
                <xs:schema attributeFormDefault="qualified"
                        elementFormDefault="unqualified" targetNamespace="http://test.sca.oasisopen.org/"
                        xmlns:xs="http://www.w3.org/2001/XMLSchema">
                        <xs:import />
                        <xs:element name="operation1Response">
                                <xs:complexType>
                                        <xs:sequence>
                                                <xs:element minOccurs="0" name="return" nillable="true"
                                                        type="xs:string" />
                                        </xs:sequence>
                                </xs:complexType>
                        </xs:element>
                        <xs:element name="operation1">
                                <xs:complexType>
                                    <xs:sequence>
                        <xs:element name="arg0" type="xs:string" minOccurs="0" maxOccurs="unbounded"/>
                    </xs:sequence>
                                </xs:complexType>
                        </xs:element>
                </xs:schema>
        </wsdl:types>
        <wsdl:message name="operation1Response">
                <wsdl:part name="operation1Response" element="tns:operation1Response">
                </wsdl:part>
        </wsdl:message>
        <wsdl:message name="operation1">
                <wsdl:part name="operation1" element="tns:operation1">
                </wsdl:part>
        </wsdl:message>
        <wsdl:portType name="Service4">
                <wsdl:operation name="operation1">
                        <wsdl:input message="tns:operation1">
                        </wsdl:input>
                        <wsdl:output message="tns:operation1Response">
                        </wsdl:output>
                </wsdl:operation>
        </wsdl:portType>
</wsdl:definitions>
The element arg0 in the global element operation1 defines a single input parameter to operation1, but this element has maxOccurs=unbounded. so the type of the parameter needs to allow multiple values. Mapping this to a DataObject would result in unnecessary overhead, more complicated client and implementation code and a lack of clarity as to the name of the property in the DataObject actually containing the data.

Proposal:
Direction
When mapping from C++ to WSDL/XML map parameters/return types with a type that is an array, or a list, vector (probably double ended queue and its variations - queue, stack and priority queue - as well) to an XML element with maxOccurs=unbounded.
When mapping from WSDL/XML to C++ map elements with maxOccurs > 1 that define parameters/return types to a list<type> where type is either the simple type of the element or DataObjectPtr>

Raised to the OASIS Service Component Architecture / C and C++ (SCA-C-C++) TC in the e-mail at http://lists.oasis-open.org/archives/sca-c-cpp/201003/msg00041.html

 Comments   
Comment by Andrew Borley [ 25/Mar/10 10:11 AM ]
Issue opened in SCA C and C++ Telcon Thursday, 25 March 2010.
See minutes at http://www.oasis-open.org/committees/event.php?event_id=26109
Comment by Andrew Borley [ 25/Mar/10 10:19 AM ]
Issue resolved in SCA C and C++ Telcon Thursday, 25 March 2010.
See minutes at http://www.oasis-open.org/committees/event.php?event_id=26109
Comment by Bryan Aupperle [ 14/Oct/10 10:49 AM ]
Included in CD06 (approved 14 Oct 2010).




[CCPP-105] ComponentContext missing commonj::sdo
Created: 11/Mar/10  Updated: 14/Oct/10

Status: Closed
Project: OASIS SCA C-CPP TC
Component/s: C++ Public Review
Affects Version/s: Version 1.1
Fix Version/s: Version 1.1

Type: Bug Priority: Major
Reporter: Andrew Borley Assigned To: Bryan Aupperle
Resolution: Fixed Votes: 0


 Description   
Target C++ C&I Spec (CD 05)

Description: ComponentContext includes the member functions:
 virtual DataObjectPtr getProperties();
  virtual DataFactoryPtr getDataFactory();
The return value of the functions are define by the OSOA SDO for C++ specification: http://www.osoa.org/download/attachments/36/CPP-SDO-Spec-v2.1.0-FINAL.pdf and in that specification the namespace for the return values is commonj::sdo.

Proposal: Add the namespace qualifiers so the definitions become:
  virtual commonj::sdo::DataObjectPtr getProperties();
  virtual commonj::sdo::DataFactoryPtr getDataFactory();
This changes needs to be made in both the specification (seciton 6.2) and ComponentContext.h (with a #include "commonj/sdo/sdo.h" added).

Raised to the OASIS Service Component Architecture / C and C++ (SCA-C-C++) TC in the e-mail at http://lists.oasis-open.org/archives/sca-c-cpp/201003/msg00040.html

 Comments   
Comment by Andrew Borley [ 25/Mar/10 10:10 AM ]
Issue opened in SCA C and C++ Telcon Thursday, 25 March 2010.
See minutes at http://www.oasis-open.org/committees/event.php?event_id=26109
Comment by Andrew Borley [ 25/Mar/10 10:43 AM ]
Issue resolved in SCA C and C++ Telcon Thursday, 25 March 2010.
See minutes at http://www.oasis-open.org/committees/event.php?event_id=26109
Comment by Bryan Aupperle [ 14/Oct/10 10:49 AM ]
Included in CD06 (approved 14 Oct 2010).




[CCPP-104] RDDL problems and missing header files (C)
Created: 03/Mar/10  Updated: 05/Mar/10

Status: Closed
Project: OASIS SCA C-CPP TC
Component/s: C Public Review
Affects Version/s: Version 1.1
Fix Version/s: Version 1.1

Type: Bug Priority: Major
Reporter: Bryan Aupperle Assigned To: Bryan Aupperle
Resolution: Fixed Votes: 0


 Description   
From a post to the sca-c-cpp-comment list:
http://lists.oasis-open.org/archives/sca-c-cpp-comment/201003/msg00000.html

This is Microsoft's public comment about the following two specifications under public review per announcement [1]:
  
- Service Component Architecture Client and Implementation Model for C++ Specification Version 1.1
- Service Component Architecture Client and Implementation Model for C Specification Version 1.1
  
We have been attempting to review the above specifications, but have been unable to complete our review due the following problems with the specifications as published:
  
1) The revised C and C++ specifications http://docs.oasis-open.org/opencsa/sca-c-cpp/sca-ccni-1.1-spec-cd04.pdf and http://docs.oasis-open.org/opencsa/sca-c-cpp/sca-cppcni-1.1-spec-cd04.html include markup to indicate changes but we could not find where the clean versions are provided. There is enough markup in these documents to make the document impossible to review in places.
  
2) The RDDL document for http://docs.oasis-open.org/ns/opencsa/sca/200912 refers to at least two XML Schema documents that are not valid. For example the first XML schema listed (http://docs.oasis-open.org/opencsa/sca-assembly/sca-1.1-cd05.xsd) apparently contains invalid whitespace, and the 5th item (http://docs.oasis-open.org/opencsa/sca-assembly/sca-policy-1.1-intents-definitions-cd03.xsd)returns "HTTP 404 Not Found" error.
  
3) The RDDL document for http://docs.oasis-open.org/ns/opencsa/sca/200912 refers to at least one XML Schema document that returns a 404. For example the 5th XML Schema listed (http://docs.oasis-open.org/opencsa/sca-assembly/sca-policy-1.1-intents-definitions-cd03.xsd) is not retrievable (404 error).
  
4) But the biggest obstacle in our reviewing of the specifications is the fact that the required C/C++ header files are missing from the specifications. Without being able to review the C/C++ header files, it is impossible to perform a complete and meaningful review of the specifications.
  
Sincerely,
Michael Champion,
Microsoft Corporation
  
[1] http://lists.oasis-open.org/archives/tc-announce/201002/msg00005.html

 Comments   
Comment by Andrew Borley [ 04/Mar/10 10:08 AM ]
Issue opened in SCA C and C++ Telcon Thursday, 4 March 2010.
See minutes at http://www.oasis-open.org/committees/event.php?event_id=26106
Comment by Andrew Borley [ 04/Mar/10 10:24 AM ]
Issue resolved in SCA C and C++ Telcon Thursday, 4 March 2010.
See minutes at http://www.oasis-open.org/committees/event.php?event_id=26106
Comment by Bryan Aupperle [ 05/Mar/10 08:36 AM ]
Included in CD04 (approved 4 Mar. 2010).




[CCPP-103] RDDL problems and missing header files (C++)
Created: 03/Mar/10  Updated: 05/Mar/10

Status: Closed
Project: OASIS SCA C-CPP TC
Component/s: C++ Public Review
Affects Version/s: Version 1.1
Fix Version/s: Version 1.1

Type: Bug Priority: Major
Reporter: Bryan Aupperle Assigned To: Bryan Aupperle
Resolution: Fixed Votes: 0


 Description   
From a post to the sca-c-cpp-comment list:
http://lists.oasis-open.org/archives/sca-c-cpp-comment/201003/msg00000.html

This is Microsoft's public comment about the following two specifications under public review per announcement [1]:
  
- Service Component Architecture Client and Implementation Model for C++ Specification Version 1.1
- Service Component Architecture Client and Implementation Model for C Specification Version 1.1
  
We have been attempting to review the above specifications, but have been unable to complete our review due the following problems with the specifications as published:
  
1) The revised C and C++ specifications http://docs.oasis-open.org/opencsa/sca-c-cpp/sca-ccni-1.1-spec-cd04.pdf and http://docs.oasis-open.org/opencsa/sca-c-cpp/sca-cppcni-1.1-spec-cd04.html include markup to indicate changes but we could not find where the clean versions are provided. There is enough markup in these documents to make the document impossible to review in places.
  
2) The RDDL document for http://docs.oasis-open.org/ns/opencsa/sca/200912 refers to at least two XML Schema documents that are not valid. For example the first XML schema listed (http://docs.oasis-open.org/opencsa/sca-assembly/sca-1.1-cd05.xsd) apparently contains invalid whitespace, and the 5th item (http://docs.oasis-open.org/opencsa/sca-assembly/sca-policy-1.1-intents-definitions-cd03.xsd)returns "HTTP 404 Not Found" error.
  
3) The RDDL document for http://docs.oasis-open.org/ns/opencsa/sca/200912 refers to at least one XML Schema document that returns a 404. For example the 5th XML Schema listed (http://docs.oasis-open.org/opencsa/sca-assembly/sca-policy-1.1-intents-definitions-cd03.xsd) is not retrievable (404 error).
  
4) But the biggest obstacle in our reviewing of the specifications is the fact that the required C/C++ header files are missing from the specifications. Without being able to review the C/C++ header files, it is impossible to perform a complete and meaningful review of the specifications.
  
Sincerely,
Michael Champion,
Microsoft Corporation
  
[1] http://lists.oasis-open.org/archives/tc-announce/201002/msg00005.html


 Comments   
Comment by Andrew Borley [ 04/Mar/10 10:08 AM ]
Issue opened in SCA C and C++ Telcon Thursday, 4 March 2010.
See minutes at http://www.oasis-open.org/committees/event.php?event_id=26106
Comment by Andrew Borley [ 04/Mar/10 10:23 AM ]
Issue resolved in SCA C and C++ Telcon Thursday, 4 March 2010.
See minutes at http://www.oasis-open.org/committees/event.php?event_id=26106
Comment by Bryan Aupperle [ 05/Mar/10 08:36 AM ]
Included in CD04 (approved 4 Mar. 2010).




[CCPP-102] Precedence of code artifacts
Created: 05/Jan/10  Updated: 23/Feb/10

Status: Closed
Project: OASIS SCA C-CPP TC
Component/s: C specification, C++ specification
Affects Version/s: Version 1.1
Fix Version/s: Version 1.1

Type: Bug Priority: Major
Reporter: Andrew Borley Assigned To: Bryan Aupperle
Resolution: Fixed Votes: 0


 Description   
 Target C++ and C C&I Specs (CD 03 Rev 4 of each)

Description: Section 11 has the text:
        For code artifacts related to this specification, the specification text is considered to be authoritative and takes precedence over the code artifacts.
This text is in conflict with the updated OASIS TC process, approved last year, which states that external documents such as schema, code, etc) take precedence over specification text.

Proposal: revise the wording to:
        Normative code artifacts related to this specification are considered to be authoritative and take precedence over specification text.

Raised to the OASIS Service Component Architecture / C and C++ (SCA-C-C++) TC in the e-mail at http://lists.oasis-open.org/archives/sca-c-cpp/201001/msg00000.html

 Comments   
Comment by Andrew Borley [ 14/Jan/10 10:09 AM ]
Issue opened in SCA C and C++ Telcon Thursday, 14 January 2010.
See minutes at http://www.oasis-open.org/committees/event.php?event_id=26099
Comment by Andrew Borley [ 14/Jan/10 10:15 AM ]
Issue resolved in SCA C and C++ Telcon Thursday, 14 January 2010.
See minutes at http://www.oasis-open.org/committees/event.php?event_id=26099
Comment by Bryan Aupperle [ 17/Feb/10 09:01 AM ]
Included in CD04 (approved 21 Jan 2010).




[CCPP-101] Update SCA namespace to ...200912
Created: 14/Dec/09  Updated: 23/Feb/10

Status: Closed
Project: OASIS SCA C-CPP TC
Component/s: C specification, C++ specification
Affects Version/s: Version 1.1
Fix Version/s: Version 1.1

Type: Bug Priority: Major
Reporter: Andrew Borley Assigned To: Bryan Aupperle
Resolution: Fixed Votes: 0


 Description   
Target C++ C&I Spec and C C&I Spec (CD 03 Rev 4 of each)

Description: As described in a note from Mike Edwards, the Assembly TC has changed the date identifier of the SCA namespace to be 200912.

Proposal: Update all uses of/references to the SCA namespace to have a date of 200912

Raised to the OASIS Service Component Architecture / C and C++ (SCA-C-C++) TC in the e-mail at http://lists.oasis-open.org/archives/sca-c-cpp/200912/msg00009.html

 Comments   
Comment by Andrew Borley [ 14/Jan/10 10:09 AM ]
Issue opened in SCA C and C++ Telcon Thursday, 14 January 2010.
See minutes at http://www.oasis-open.org/committees/event.php?event_id=26099
Comment by Andrew Borley [ 14/Jan/10 10:15 AM ]
Issue resolved in SCA C and C++ Telcon Thursday, 14 January 2010.
See minutes at http://www.oasis-open.org/committees/event.php?event_id=26099
Comment by Bryan Aupperle [ 17/Feb/10 09:01 AM ]
Included in CD04 (approved 21 Jan 2010).




[CCPP-100] Add Requires and PolicySetAttachment elements
Created: 14/Dec/09  Updated: 23/Feb/10

Status: Closed
Project: OASIS SCA C-CPP TC
Component/s: C specification, C++ specification
Affects Version/s: Version 1.1
Fix Version/s: Version 1.1

Type: Bug Priority: Major
Reporter: Andrew Borley Assigned To: Bryan Aupperle
Resolution: Fixed Votes: 0


 Description   
Target C++ C&I Spec and C C&I Spec (CD 03 Rev 4 of each)

Description: The Assembly TC has (at the request of of the Policy TC) added requires and policySetAttachment elements to commonExtensionBase, which is the bases for interface and implementation and thus interface.cp, interface.c, implementation.cpp and implementation.c

Proposal: Add the requires and policySetAttachment elements to the effected pseudo-schema (including descriptions) and also added these elements to the function and callbackFunction child elements of the effected schema, psuedo-schama (including descriptions).

Raised to the OASIS Service Component Architecture / C and C++ (SCA-C-C++) TC in the e-mail at http://lists.oasis-open.org/archives/sca-c-cpp/200912/msg00011.html

 Comments   
Comment by Andrew Borley [ 14/Jan/10 10:08 AM ]
Issue opened in SCA C and C++ Telcon Thursday, 14 January 2010.
See minutes at http://www.oasis-open.org/committees/event.php?event_id=26099
Comment by Andrew Borley [ 14/Jan/10 10:13 AM ]
Issue resolved in SCA C and C++ Telcon Thursday, 14 January 2010.
See minutes at http://www.oasis-open.org/committees/event.php?event_id=26099
Comment by Bryan Aupperle [ 17/Feb/10 09:01 AM ]
Included in CD04 (approved 21 Jan 2010).




[CCPP-99] Remove constrainingType references from specs
Created: 13/Oct/09  Updated: 23/Feb/10

Status: Closed
Project: OASIS SCA C-CPP TC
Component/s: C specification, C++ specification
Affects Version/s: Version 1.1
Fix Version/s: Version 1.1

Type: Bug Priority: Major
Reporter: Andrew Borley Assigned To: Bryan Aupperle
Resolution: Fixed Votes: 0


 Description   
Target C++ C&I Spec and C C&I Spec (CD 03 Rev 4 of each)

Description: Because the Assembly TC has removed constrainingType from SCA, all references to constrainingType must be removed from the C++ and C C&I specs.

Proposal:
C++: Remove constrainingType from CPP110002, point 5 of section 11.2 and the second paragraph of point 2 of section 11.3.
C: Remove constrainingType from C110002, point 6 of section 11.2 and the second paragraph of point 2 of section 11.3.

Raised to the OASIS Service Component Architecture / C and C++ (SCA-C-C++) TC in the e-mail at http://lists.oasis-open.org/archives/sca-c-cpp/200910/msg00015.html

 Comments   
Comment by Andrew Borley [ 15/Oct/09 10:09 AM ]
Issue opened in SCA C and C++ Telcon Thursday, 15 October 2009.
See minutes at http://www.oasis-open.org/apps/group_public/event.php?event_id=24742
Comment by Andrew Borley [ 15/Oct/09 10:11 AM ]
Issue resolved in SCA C and C++ Telcon Thursday, 15 October 2009.
See minutes at http://www.oasis-open.org/apps/group_public/event.php?event_id=24742
Comment by Bryan Aupperle [ 17/Feb/10 09:01 AM ]
Included in CD04 (approved 21 Jan 2010).




[CCPP-98] CPP20012 and C20014 are misleading
Created: 11/Oct/09  Updated: 23/Feb/10

Status: Closed
Project: OASIS SCA C-CPP TC
Component/s: C specification, C++ specification
Affects Version/s: Version 1.1
Fix Version/s: Version 1.1

Type: Bug Priority: Major
Reporter: Andrew Borley Assigned To: Bryan Aupperle
Resolution: Fixed Votes: 0


 Description   

Target: CPPCNI CD04 Rev4 and CCNI CD04 Rev4

Description: CPP20012 and C20014 both state: An SCA runtime MUST ensure that a stateless scoped implementation instance object is only ever dispatched on one thread at any one time. In addition, within the SCA lifecycle of an instance, an SCA runtime MUST only make a single invocation of one business function.

If an implementation truly is stateless - i.e. does not use static variables and only uses data members (C++) global variables (C, a stateless C++ implementation should never access a global variable for holding property values - than this statement is unnecessary.

The question becomes what kind of protection can a runtime provide for in implementation identified as stateless that is not truly so. Static and global variables exist as long as the library containing them resides in memory and it is not possible to guarantee that a library can be unloaded after an arbitrary function invocation. The second sentence of the normative statements implies a level of protection that is simply not possible to provide. And newing/freeing an object after every member function invocation is a performance hit.

The first sentence does not have any problematic implications, but I think is meaningless in C.to the extent that a function invocation only exists on one thread.

Proposal: At a minimum, the second sentence of CPP20012 and C20014 should be deleted. We should discuss if any other changes are appropriate.

Raised to the OASIS Service Component Architecture / C and C++ (SCA-C-C++) TC in the e-mail at http://lists.oasis-open.org/archives/sca-c-cpp/200910/msg00010.html

 Comments   
Comment by Andrew Borley [ 15/Oct/09 10:09 AM ]
Issue opened in SCA C and C++ Telcon Thursday, 15 October 2009.
See minutes at http://www.oasis-open.org/apps/group_public/event.php?event_id=24742
Comment by Andrew Borley [ 12/Nov/09 10:06 AM ]
Issue resolved in SCA C and C++ Telcon Thursday, 12 November 2009.
See minutes at http://www.oasis-open.org/committees/event.php?event_id=24746
Comment by Bryan Aupperle [ 17/Feb/10 09:00 AM ]
Included in CD04 (approved 21 Jan 2010).




[CCPP-97] SOAP intent qualifiers have to be renamed
Created: 26/Aug/09  Updated: 23/Feb/10

Status: Closed
Project: OASIS SCA C-CPP TC
Component/s: C specification, C++ specification
Affects Version/s: Version 1.1
Fix Version/s: Version 1.1

Type: Bug Priority: Major
Reporter: Andrew Borley Assigned To: Bryan Aupperle
Resolution: Fixed Votes: 0


 Description   
TARGET:C++ and C C&I specs - CD03 Rev 3 of each

DESCRIPTION:
Intent qualifier names are NCNames as defined by the Policy FW spec and our annotation grammar. NCNames cannot start with a digit, which is exactly how the SOAP intent qualifiers are defined. This was found in the SCA Policy TC and was fixed in POLICY-103 by renaming the qualifiers to 'v1_1' and 'v1_2'.

PROPOSAL:
Update Table B-5 in each spec to match the new SOAP intent qualifier names. The proposal is to replace '1_1' with 'v1_1' and to replace '1_2' with 'v1_2'.



 Comments   
Comment by Andrew Borley [ 27/Aug/09 10:12 AM ]
Issue opened in SCA C and C++ Telcon Thursday, 27 August 2009.
See minutes at http://www.oasis-open.org/committees/event.php?event_id=24735
Comment by Andrew Borley [ 27/Aug/09 10:49 AM ]
Issue resolved in SCA C and C++ Telcon Thursday, 27 August 2009.
See minutes at http://www.oasis-open.org/committees/event.php?event_id=24735
Comment by Bryan Aupperle [ 17/Feb/10 09:00 AM ]
Included in CD04 (approved 21 Jan 2010).




[CCPP-96] Inconsistent function exclusion
Created: 17/Aug/09  Updated: 17/Feb/10

Status: Closed
Project: OASIS SCA C-CPP TC
Component/s: C specification
Affects Version/s: None
Fix Version/s: None

Type: Bug Priority: Major
Reporter: Bryan Aupperle Assigned To: Bryan Aupperle
Resolution: Fixed Votes: 0


 Description   
Target: C C&I Specifications (CD03 Rev 3)

Description:
Currently we have normative statements that say that an @WebFunction annotation implies an @Operation annotation and the other way around (CA0004 and CC0002). But the implications of having some functions annotate with one are different than the other. If any function is annotated with @Operations than only annotated functions are included in interface. However, a function annotated with @WebFunction does not automatically exclude non-annotated functions.

Proposal:
(Direction - Full text will be needed)

Add an exclude attribute to the @Operation annotation for functions and have it work like the same attribute on @WebFunction

Raised to the OASIS Service Component Architecture / C and C++ (SCA-C-C++) TC in the e-mail at http://lists.oasis-open.org/archives/sca-c-cpp/200908/msg00016.html

 Comments   
Comment by Andrew Borley [ 27/Aug/09 10:10 AM ]
Issue opened in SCA C and C++ Telcon Thursday, 27 August 2009.
See minutes at http://www.oasis-open.org/committees/event.php?event_id=24735
Comment by Andrew Borley [ 10/Sep/09 10:07 AM ]
Issue resolved in SCA C and C++ Telcon Thursday, 10 September 2009.
See minutes at http://www.oasis-open.org/committees/event.php?event_id=24737
Comment by Bryan Aupperle [ 17/Feb/10 09:00 AM ]
Included in CD04 (approved 21 Jan 2010).




[CCPP-95] @WebService vs. @Interface & @Remotable
Created: 17/Aug/09  Updated: 17/Feb/10

Status: Closed
Project: OASIS SCA C-CPP TC
Component/s: C specification, C++ specification
Affects Version/s: Version 1.1
Fix Version/s: Version 1.1

Type: Bug Priority: Major
Reporter: Bryan Aupperle Assigned To: Bryan Aupperle
Resolution: Fixed Votes: 0


 Description   
Target: C++ and C C&I Specifications (CD03 Rev 3)

Description:
Currently we have normative statements that say that an @WebService annotation implies an @Interface annotation and the other way around (CPPA0003 and CPPC0002 / CA0003 and CC0001). This association would be appropriate if all interfaces were remotable, but that is not the case. We could have an @Interface annotation with no @Remotable annotation, and it would not be necessary or appropriate to imply an @WebService annotation. Similarly, @WebService does imply @Remotable, but this is not stated.

@Interface is only used in C++ when there are multiple classes in a header file and not all define SCA interfaces. It is used in C when multiple interfaces are defined within a header file or to control the name of the service defined by the interface.

For C++ @Remotable should also imply @Interface, but this is not stated.

Proposal:
(Direction - Full text will be needed)

For C++:
@Remotable => @Interface (this would mean that @interface would only be used for local interfaces when multiple classes are present in a header file).
@Remotable => @WebService and @WebService => @Remotable (replace @Interface with @Remotable in the two normative statements)

For C:
@Remotable is additive to @Interface (as it is now)
@Remotable => @WebService and @WebService => @Remotable and @Interface if necessary (rewording the normative statements)

Raised to the OASIS Service Component Architecture / C and C++ (SCA-C-C++) TC in the e-mail at http://lists.oasis-open.org/archives/sca-c-cpp/200908/msg00015.html

 Comments   
Comment by Andrew Borley [ 27/Aug/09 10:12 AM ]
Issue opened in SCA C and C++ Telcon Thursday, 27 August 2009.
See minutes at http://www.oasis-open.org/committees/event.php?event_id=24735
Comment by Andrew Borley [ 03/Sep/09 10:18 AM ]
Issue resolved in SCA C and C++ Telcon Thursday, 3 September 2009.
See minutes at http://www.oasis-open.org/committees/event.php?event_id=24736
Comment by Bryan Aupperle [ 17/Feb/10 08:59 AM ]
Included in CD04 (approved 21 Jan 2010).




[CCPP-94] Binding naming inconsistent with JAX-WS
Created: 17/Aug/09  Updated: 17/Feb/10

Status: Closed
Project: OASIS SCA C-CPP TC
Component/s: C specification, C++ specification
Affects Version/s: Version 1.1
Fix Version/s: Version 1.1

Type: Bug Priority: Major
Reporter: Bryan Aupperle Assigned To: Bryan Aupperle
Resolution: Fixed Votes: 0


 Description   
Target: C++ and C C&I Specifications (CD03 Rev 3)

Description:
The Default name for a WSDL binding in section C.1.1 is inconsistent with JAX-WS. JAX-WS appends "Binding" to the portType (see section 3.8.1 of the JAX-WS spec).
The C++ and C specs have the statement 'In the case of a SOAP binding, the binding name is the name of the service suffixed with "SoapBinding".'

Proposal:
Change the above statement to: 'In the case of a SOAP binding, the binding name is the name of the portType suffixed with "Binding".'

Raised to the OASIS Service Component Architecture / C and C++ (SCA-C-C++) TC in the e-mail at http://lists.oasis-open.org/archives/sca-c-cpp/200908/msg00012.html

 Comments   
Comment by Andrew Borley [ 27/Aug/09 10:08 AM ]
Issue opened in SCA C and C++ Telcon Thursday, 27 August 2009.
See minutes at http://www.oasis-open.org/committees/event.php?event_id=24735
Comment by Andrew Borley [ 27/Aug/09 10:33 AM ]
Issue resolved in SCA C and C++ Telcon Thursday, 27 August 2009.
See minutes at http://www.oasis-open.org/committees/event.php?event_id=24735
Comment by Bryan Aupperle [ 17/Feb/10 08:59 AM ]
Included in CD04 (approved 21 Jan 2010).




[CCPP-93] Duplicate Normative statements
Created: 17/Aug/09  Updated: 17/Feb/10

Status: Closed
Project: OASIS SCA C-CPP TC
Component/s: C specification, C++ specification
Affects Version/s: Version 1.1
Fix Version/s: Version 1.1

Type: Bug Priority: Major
Reporter: Bryan Aupperle Assigned To: Bryan Aupperle
Resolution: Fixed Votes: 0


 Description   
Target: C++ and C C&I Specifications (CD03 Rev 3)

Description:
There are duplicate normative statements regarding the naming of WSDL Ports in section C.1.1 (@WebService) and appendix F.3/ F.4 (JAX-WS Normative Statements). Specifically:
C++: CPPC0003 and CPPF0042
C: CC0008 and CF0032

Proposal:
Remove the Normative statement in F.3/F/4. Add a reference to the normative statement in section C.1.1 (More accurately in F.1/F.2) in the notes column of table F.4/F.5.
Modify the wording of CPPC0003/CC0008 to 'If a @WebService does not have a portName element, an SCA implementation MUST use the value, explicit or default, associated with the name element, suffixed with "Port".'

Raised to the OASIS Service Component Architecture / C and C++ (SCA-C-C++) TC in the e-mail at http://lists.oasis-open.org/archives/sca-c-cpp/200908/msg00011.html

 Comments   
Comment by Andrew Borley [ 27/Aug/09 10:06 AM ]
Issue opened in SCA C and C++ Telcon Thursday, 27 August 2009.
See minutes at http://www.oasis-open.org/committees/event.php?event_id=24735
Comment by Andrew Borley [ 03/Sep/09 10:09 AM ]
Issue resolved in SCA C and C++ Telcon Thursday, 3 September 2009.
See minutes at http://www.oasis-open.org/committees/event.php?event_id=24736
Comment by Bryan Aupperle [ 17/Feb/10 08:59 AM ]
Included in CD04 (approved 21 Jan 2010).




[CCPP-92] C API needs multiple value property retrieval
Created: 29/Jul/09  Updated: 17/Feb/10

Status: Closed
Project: OASIS SCA C-CPP TC
Component/s: C specification
Affects Version/s: Version 1.1
Fix Version/s: Version 1.1

Type: Bug Priority: Major
Reporter: Andrew Borley Assigned To: Bryan Aupperle
Resolution: Fixed Votes: 0


 Description   
Target: C C&I CD03 Rev 2

Description:
The current API definition only provides functions for retrieving single property values. However, it is possible to define a property that can have multiple values. It is possible to retrieve the multiple values as an SDO, but SDO support is optional. There needs to be a way to retrieve multiple values without using an SDO.

Discussion:
There are two options
1) Duplicate the current SCAProperty<T>() functions as SCAPropertyIndex<T> adding a index parameter to the new functions (all 15 of them). The new functions would retrieve the value at the specified index.

2) Add a SCAPropertyIndex(name, index, ...) which would set the index and return an error if there is no value at the index. A subsequent SCAProperty<T>() call would return the value at the index.

index - 0;
SCAPropertyIndex(prop, index &cc, &reason);
while (reason != DATA_TRUNCATED) {
   SCAPropertyCString(prop, &Value[i], size, &cc, &reason);
   index ++;
   SCAPropertyIndex(prop, index, &cc, &reason);
}

Raised to the OASIS Service Component Architecture / C and C++ (SCA-C-C++) TC in the e-mail at http://lists.oasis-open.org/archives/sca-c-cpp/200907/msg00036.html

 Comments   
Comment by Andrew Borley [ 30/Jul/09 10:11 AM ]
Issue opened in SCA C and C++ Telcon Thursday, 30 July 2009.
See minutes at http://www.oasis-open.org/committees/event.php?event_id=24731
Comment by Andrew Borley [ 27/Aug/09 10:20 AM ]
Issue resolved in SCA C and C++ Telcon Thursday, 27 August 2009.
See minutes at http://www.oasis-open.org/committees/event.php?event_id=24735
Comment by Bryan Aupperle [ 17/Feb/10 08:58 AM ]
Included in CD04 (approved 21 Jan 2010).




[CCPP-91] Minor C API changes
Created: 29/Jul/09  Updated: 17/Feb/10

Status: Closed
Project: OASIS SCA C-CPP TC
Component/s: C specification
Affects Version/s: Version 1.1
Fix Version/s: Version 1.1

Type: Bug Priority: Major
Reporter: Andrew Borley Assigned To: Bryan Aupperle
Resolution: Fixed Votes: 0


 Description   
Target: C C&I Specification (CD03 Rev 2)

Description:
While working on the test cases for the C API, I noticed an error and some signatures that could be improved. Specifically

void SCAPropertyStruct(wchar_t *propertyName,
                           void **value, <- should be a single level pointer: void *value
                           int *compCode,
                           int *reason);

void SCAGetReplyMessage(SCAREF token,
                        int *bufferLen,
                        char *buffer, <- should be a void *
                        int *compCode,
                        int *reason);

void SCAGetFaultMessage(SCAREF token,
                        int *bufferLen,
                        wchar_t **faultName,
                        char *buffer, <- should be a void *
                        int *compCode,
                        int *reason);

void SCASetFaultMessage(wchar_t *serviceName,
                        wchar_t *operationName,
                        wchar_t *faultName,
                        int bufferLen,
                        char *buffer, <- should be a void *
                        int *compCode,
                        int *reason);

Proposal:
See above

Raised to the OASIS Service Component Architecture / C and C++ (SCA-C-C++) TC in the e-mail at http://lists.oasis-open.org/archives/sca-c-cpp/200907/msg00035.html

 Comments   
Comment by Andrew Borley [ 30/Jul/09 10:10 AM ]
Issue opened in SCA C and C++ Telcon Thursday, 30 July 2009.
See minutes at http://www.oasis-open.org/committees/event.php?event_id=24731
Comment by Andrew Borley [ 30/Jul/09 10:12 AM ]
Issue resolved in SCA C and C++ Telcon Thursday, 30 July 2009.
See minutes at http://www.oasis-open.org/committees/event.php?event_id=24731
Comment by Bryan Aupperle [ 17/Feb/10 08:58 AM ]
Included in CD04 (approved 21 Jan 2010).




[CCPP-90] Improper use of MAY
Created: 22/Jul/09  Updated: 17/Feb/10

Status: Closed
Project: OASIS SCA C-CPP TC
Component/s: C specification, C++ specification
Affects Version/s: Version 1.1
Fix Version/s: Version 1.1

Type: Bug Priority: Major
Reporter: Andrew Borley Assigned To: Bryan Aupperle
Resolution: Fixed Votes: 0


 Description   
Target: C++ C&I spec and C C&I spec CD03 Rev 2 of both

Description:
Based on discussions in some of the other SCA TCs., the conformance point for @WebParam relative to named vs. unnamed parameters is an improper use of the MAY keyword. This is not an optional implementation point, In fact, there is implied, required behavior of an implementation.

Proposal:
Change: The value of the paramName of a @WebParam annotation MUST be the name of a parameter of the member function the annotation is applied to; unnamed parameters MUST NOT be referenced by a @WebParam annotation.
to: The value of the paramName of a @WebParam annotation MUST be the name of a parameter of the member function the annotation is applied to; unnamed parameters MUST NOT be referenced by a @WebParam annotation.

Raised to the OASIS Service Component Architecture / C and C++ (SCA-C-C++) TC in the e-mail at http://lists.oasis-open.org/archives/sca-c-cpp/200907/msg00026.html

 Comments   
Comment by Andrew Borley [ 23/Jul/09 10:13 AM ]
Issue opened in SCA C and C++ Telcon Thursday, 23 July 2009.
See minutes at http://www.oasis-open.org/committees/event.php?event_id=24730
Comment by Andrew Borley [ 23/Jul/09 01:43 PM ]
Issue resolved in SCA C and C++ Telcon Thursday, 23 July 2009.
See minutes at http://www.oasis-open.org/committees/event.php?event_id=24730
Comment by Bryan Aupperle [ 17/Feb/10 08:58 AM ]
Included in CD04 (approved 21 Jan 2010).




[CCPP-89] Schema should not contain anyAttrribute
Created: 22/Jul/09  Updated: 17/Feb/10

Status: Closed
Project: OASIS SCA C-CPP TC
Component/s: C specification, C++ specification
Affects Version/s: Version 1.1
Fix Version/s: Version 1.1

Type: Bug Priority: Major
Reporter: Andrew Borley Assigned To: Bryan Aupperle
Resolution: Fixed Votes: 0


 Description   

Target: C++ C&I spec and C C&I spec CD03 Rev 2 of both

Description:
In the preparation for the PR of the Bindings specs, it was noted that there was an error in the extensibility points of the schema. Specifically, the inclusion of anyAttribute in the binding schemas is not only unnecessary but can lead to problems for some parsers. This is because the bindings schema are ultimately extensions of commonExtensionBase in the core SCA schema which itself includes anyAttribute.

The same problem exists in implementation.cpp, implementation.c, interface.cpp and interface.c.

Proposal:
Remove anyAttribute from implementation.cpp, implementation.c, interface.cpp and interface.c.

Raised to the OASIS Service Component Architecture / C and C++ (SCA-C-C++) TC in the e-mail at http://lists.oasis-open.org/archives/sca-c-cpp/200907/msg00025.html

 Comments   
Comment by Andrew Borley [ 23/Jul/09 10:13 AM ]
Issue opened in SCA C and C++ Telcon Thursday, 23 July 2009.
See minutes at http://www.oasis-open.org/committees/event.php?event_id=24730
Comment by Andrew Borley [ 23/Jul/09 01:44 PM ]
Issue resolved in SCA C and C++ Telcon Thursday, 23 July 2009.
See minutes at http://www.oasis-open.org/committees/event.php?event_id=24730
Comment by Bryan Aupperle [ 17/Feb/10 08:58 AM ]
Included in CD04 (approved 21 Jan 2010).




[CCPP-88] XML Snippets should not contain encoding declaration
Created: 22/Jul/09  Updated: 17/Feb/10

Status: Closed
Project: OASIS SCA C-CPP TC
Component/s: C specification, C++ specification
Affects Version/s: Version 1.1
Fix Version/s: Version 1.1

Type: Bug Priority: Major
Reporter: Andrew Borley Assigned To: Bryan Aupperle
Resolution: Fixed Votes: 0


 Description   
Target: C++ C&I spec and C C&I spec CD03 Rev 2 of both

Description:
Here is a excerpt of an exchanged that took place in the Bindings TC. The points being made are applicable to our specs as well.

But of more important, as a general rule, I don't think we should include encoding in inlined text examples in any of our specs. It doesn't make a lot of sense.
XML files without encoding attribute on the XML declaration is valid and usually not necessary especially when BOM takes care of it.

I agree, we could have just removed the entire line and it wouldn't harm the example. The fact that it was an example may lead someone to copy/paste it and then later get surprised by the encoding as they modify it. If the line is there, I think it's a better practice to make it portable.

I agree that encoding="ASCII" in our examples is a bad idea. But it should not be assumed that sticking UTF-8 necessarily solves all the problems of cut-paste-edit. The editor used may not recognize the XML encoding attribute (or is it pseudo-attribute?) and may save it in a non-UTF8 format. This (UTF-16) is actually not uncommon for say Japanese characters, where UTF-16 is preferred as it results in a smaller disk size for the file. If portability is a concern *and* if the XML decl is to be retained, we should not include the encoding pseudo-attribute at all. The assumption here being that in the cut-paste-edit scenario the editor would do the Right Thing wrt byte-order marks. I think this is a safer assumption.

Note the suggestion in the second paragraph.

Proposal:
Remove lines of the form: <?xml version="1.0" encoding="..."?> from all snippets

Raised to the OASIS Service Component Architecture / C and C++ (SCA-C-C++) TC in the e-mail at http://lists.oasis-open.org/archives/sca-c-cpp/200907/msg00024.html

 Comments   
Comment by Andrew Borley [ 23/Jul/09 10:12 AM ]
Issue opened in SCA C and C++ Telcon Thursday, 23 July 2009.
See minutes at http://www.oasis-open.org/committees/event.php?event_id=24730
Comment by Andrew Borley [ 23/Jul/09 01:45 PM ]
Issue resolved in SCA C and C++ Telcon Thursday, 23 July 2009.
See minutes at http://www.oasis-open.org/committees/event.php?event_id=24730
Comment by Bryan Aupperle [ 17/Feb/10 08:57 AM ]
Included in CD04 (approved 21 Jan 2010).




[CCPP-87] Additional C++ Editorial issues
Created: 30/Jun/09  Updated: 17/Feb/10

Status: Closed
Project: OASIS SCA C-CPP TC
Component/s: C++ Public Review
Affects Version/s: Version 1.1
Fix Version/s: Version 1.1

Type: Bug Priority: Major
Reporter: Bryan Aupperle Assigned To: Bryan Aupperle
Resolution: Fixed Votes: 0


 Description   
From a post to the sca-c-cpp-comment list:
http://lists.oasis-open.org/archives/sca-c-cpp-comment/200906/msg00006.html

Some editorial comments on the current draft:

1. Language usage needs to be consistent: "the following snippet" twice
in 2.1 and "The following code extract" in 2.3.

2. Moreover, the use of "following," or "above," or "below," creates
ambiguity about which "snippet" or "code extract" is being described.
The better practice would be to number all of them and then make
specific reference to those numbered (suggest) "code examples".

Note that the use of indirect and ambiguous references limits the
utility of the final version as others cannot make clear references to
the "code examples" either in texts, tutorials, manuals or other materials.

One could argue that the use of line numbers makes precise citation
possible, if awkward, but the ambiguity of internal referencing remains.

3. I think these are all the instances of "some:"

40 "This specification follows some naming conventions for artifacts
defined by the specification, as follows: "

52 "This specification follows some typographic conventions for some
specific constructs"

370-371 "Some member functions of an interface have behavioral
characteristics, which will be described later, that need to be
identified."

448 "Some member functions of an implementation have operational
characteristics that need to be identified." (err, care to say which ones?)

1294-1295 "No additional discussion is needed for header files, but here
are some additional considerations for executable and componentType
files discussed in the following sections." (is this all the "additional
considerations"?)

Generally "some" language is to be avoided in standards. Either we know
what we want to say or we don't.



 Comments   
Comment by Andrew Borley [ 16/Jul/09 09:28 AM ]
Issue opened in SCA C and C++ Telcon Thursday, 8 July 2009.
See minutes at http://www.oasis-open.org/committees/event.php?event_id=19340
Comment by Andrew Borley [ 23/Jul/09 01:46 PM ]
Issue resolved in SCA C and C++ Telcon Thursday, 23 July 2009.
See minutes at http://www.oasis-open.org/committees/event.php?event_id=24730
Comment by Bryan Aupperle [ 17/Feb/10 08:55 AM ]
Included in CD04 (approved 21 Jan 2010).




[CCPP-86] Editorial issue - C
Created: 25/Jun/09  Updated: 17/Jul/09

Status: Closed
Project: OASIS SCA C-CPP TC
Component/s: C Public Review
Affects Version/s: Version 1.1
Fix Version/s: Version 1.1

Type: Bug Priority: Major
Reporter: Andrew Borley Assigned To: Bryan Aupperle
Resolution: Duplicate Votes: 0


 Description   
From a post to the sca-c-cpp-comment list:
http://lists.oasis-open.org/archives/sca-c-cpp-comment/200906/msg00003.html

On line 1075, should that be a comma rather than a semicolon?

 Comments   
Comment by Andrew Borley [ 25/Jun/09 10:20 AM ]
Issue opened in SCA C and C++ Telcon Thursday, 25 June 2009.
See minutes at http://www.oasis-open.org/committees/event.php?event_id=19338
Comment by Andrew Borley [ 17/Jul/09 07:52 AM ]
Issue closed - duplicate of CCPP-62 in SCA C and C++ Telecon Thursday, 16 July 2009.
See minutes at http://www.oasis-open.org/committees/event.php?event_id=24729CCPP-62




[CCPP-85] Organisation/linages between SCA specifications
Created: 24/Jun/09  Updated: 17/Jul/09

Status: Closed
Project: OASIS SCA C-CPP TC
Component/s: C++ Public Review
Affects Version/s: Version 1.1
Fix Version/s: Version 1.1

Type: Bug Priority: Major
Reporter: Andrew Borley Assigned To: Bryan Aupperle
Resolution: No Action Votes: 0


 Description   
From a post to the sca-c-cpp-comment list:
http://lists.oasis-open.org/archives/sca-c-cpp-comment/200906/msg00005.html

It's hard to tell where to start reading the SCA specifications; I've
concentrated on Assembly and Java/C++ as that's what I intend to use.
Many of the architectural choices, and the specification details, would
be more clear if mentioned in a separate white paper or linkable
publication . The architectural choices made in the design of SCA are
interesting in of themselves, but would inform the reader, implementer,
and user as they work with the specifciations.

 Comments   
Comment by Andrew Borley [ 25/Jun/09 10:19 AM ]
Issue opened in SCA C and C++ Telcon Thursday, 25 June 2009.
See minutes at http://www.oasis-open.org/committees/event.php?event_id=19338
Comment by Andrew Borley [ 17/Jul/09 07:50 AM ]
Issue closed-no action in SCA C and C++ Telecon Thursday, 16 July 2009.
See minutes at http://www.oasis-open.org/committees/event.php?event_id=24729




[CCPP-84] Clear usages of Macros & Friend classes
Created: 24/Jun/09  Updated: 17/Feb/10

Status: Closed
Project: OASIS SCA C-CPP TC
Component/s: C++ Public Review
Affects Version/s: Version 1.1
Fix Version/s: Version 1.1

Type: Bug Priority: Major
Reporter: Andrew Borley Assigned To: Bryan Aupperle
Resolution: No Action Votes: 0


 Description   
From a post to the sca-c-cpp-comment list:
http://lists.oasis-open.org/archives/sca-c-cpp-comment/200906/msg00005.html

Technical Lines 1641-1644

It's quite clear (given the context, though not stated) why Friend
classes MUST NOT be used; it's less clear why Macros should not be. If
this is an implementation-based architectural decision, perhaps it
should be mentioned

 Comments   
Comment by Andrew Borley [ 25/Jun/09 10:19 AM ]
Issue opened in SCA C and C++ Telcon Thursday, 25 June 2009.
See minutes at http://www.oasis-open.org/committees/event.php?event_id=19338
Comment by Andrew Borley [ 17/Jul/09 07:50 AM ]
Issue closed-no action in SCA C and C++ Telecon Thursday, 16 July 2009.
See minutes at http://www.oasis-open.org/committees/event.php?event_id=24729
Comment by Bryan Aupperle [ 29/Jul/09 08:45 AM ]
Issue has was not closed on 16 July 2009.
Comment by Andrew Borley [ 22/Oct/09 10:14 AM ]
Issue resolved in SCA C and C++ Telecon Thursday, 22 October 2009.
See minutes at http://www.oasis-open.org/committees/event.php?event_id=24743
Comment by Bryan Aupperle [ 17/Feb/10 08:54 AM ]
Included in CD04 (approved 21 Jan 2010).




[CCPP-83] Compare & contrast to CORBA
Created: 24/Jun/09  Updated: 17/Jul/09

Status: Closed
Project: OASIS SCA C-CPP TC
Component/s: C++ Public Review
Affects Version/s: Version 1.1
Fix Version/s: Version 1.1

Type: Bug Priority: Major
Reporter: Andrew Borley Assigned To: Bryan Aupperle
Resolution: No Action Votes: 0


 Description   
From a post to the sca-c-cpp-comment list:
http://lists.oasis-open.org/archives/sca-c-cpp-comment/200906/msg00005.html

Technical Section 2.1.1ff

Some of this reads like reinvention of aspects of CORBA with remote
services. A compare and contrast (perhaps in a separate architectural
white paper) with other remoting techniques would make this choice
easier to review. Is this indeed a reinvention? Or is it a simple
acknowledgement that remotable and local services share some similarity
in the SCA model? More architectural discussion would make that
evaluation easier.

The specification is quite clear and seems effective, though I've not
tried to write to it.


 Comments   
Comment by Andrew Borley [ 25/Jun/09 10:18 AM ]
Issue opened in SCA C and C++ Telcon Thursday, 25 June 2009.
See minutes at http://www.oasis-open.org/committees/event.php?event_id=19338
Comment by Andrew Borley [ 17/Jul/09 07:50 AM ]
Issue closed-no action in SCA C and C++ Telecon Thursday, 16 July 2009.
See minutes at http://www.oasis-open.org/committees/event.php?event_id=24729




[CCPP-82] Editorial issues - C++
Created: 24/Jun/09  Updated: 17/Feb/10

Status: Closed
Project: OASIS SCA C-CPP TC
Component/s: C++ Public Review
Affects Version/s: Version 1.1
Fix Version/s: Version 1.1

Type: Bug Priority: Major
Reporter: Andrew Borley Assigned To: Bryan Aupperle
Resolution: No Action Votes: 0


 Description   
From a post to the sca-c-cpp-comment list:
http://lists.oasis-open.org/archives/sca-c-cpp-comment/200906/msg00005.html

Editorial lines 1152-1154
Part of the text is a heading; repair.

Editorial Lines 1758-1766
A reference to the conformance items and Appendix F would make this section read better.

Editorial General
"Error! Reference source not found" at lines 991 and 1413. Please repair.

Editorial Line 52
Reference should be made to the typographical conventions for
conformance assertions in this section. The Assembly document's handling
of conformance statements and highlighting is excellent; I recommend
that this (and all other SCA specs) follow that example.

A reference to Section 11 belongs in the typographic conventions section.




 Comments   
Comment by Andrew Borley [ 25/Jun/09 10:17 AM ]
Issue opened in SCA C and C++ Telcon Thursday, 25 June 2009.
See minutes at http://www.oasis-open.org/committees/event.php?event_id=19338
Comment by Andrew Borley [ 23/Jul/09 01:46 PM ]
Issue resolved in SCA C and C++ Telcon Thursday, 23 July 2009.
See minutes at http://www.oasis-open.org/committees/event.php?event_id=24730
Comment by Bryan Aupperle [ 17/Feb/10 08:54 AM ]
Included in CD04 (approved 21 Jan 2010).




[CCPP-81] The ServiceProxy base class is empty
Created: 24/Jun/09  Updated: 17/Jul/09

Status: Closed
Project: OASIS SCA C-CPP TC
Component/s: C++ Public Review
Affects Version/s: Version 1.1
Fix Version/s: Version 1.1

Type: Bug Priority: Major
Reporter: Andrew Borley Assigned To: Bryan Aupperle
Resolution: No Action Votes: 0


 Description   
From a post to the sca-c-cpp-comment list:
http://lists.oasis-open.org/archives/sca-c-cpp-comment/200906/msg00002.html

The ServiceProxy base class is empty... is it really needed?

 Comments   
Comment by Andrew Borley [ 25/Jun/09 10:10 AM ]
Issue opened in SCA C and C++ Telcon Thursday, 25 June 2009.
See minutes at http://www.oasis-open.org/committees/event.php?event_id=19338
Comment by Andrew Borley [ 17/Jul/09 07:50 AM ]
Issue closed-no action in SCA C and C++ Telecon Thursday, 16 July 2009.
See minutes at http://www.oasis-open.org/committees/event.php?event_id=24729




[CCPP-80] Framework/container to manage components
Created: 24/Jun/09  Updated: 17/Jul/09

Status: Closed
Project: OASIS SCA C-CPP TC
Component/s: C++ Public Review
Affects Version/s: Version 1.1
Fix Version/s: Version 1.1

Type: Bug Priority: Major
Reporter: Andrew Borley Assigned To: Bryan Aupperle
Resolution: No Action Votes: 0


 Description   
From a post to the sca-c-cpp-comment list:
http://lists.oasis-open.org/archives/sca-c-cpp-comment/200906/msg00002.html

It is unclear what the notion of "SCA runtime" corresponds to in C++. Is there a particular framework or container (in C++) to manage components? For example, what entity is raising SCA Exceptions ? (as opposed to business exceptions).

 Comments   
Comment by Andrew Borley [ 25/Jun/09 10:10 AM ]
Issue opened in SCA C and C++ Telcon Thursday, 25 June 2009.
See minutes at http://www.oasis-open.org/committees/event.php?event_id=19338
Comment by Andrew Borley [ 17/Jul/09 07:50 AM ]
Issue closed-no action in SCA C and C++ Telecon Thursday, 16 July 2009.
See minutes at http://www.oasis-open.org/committees/event.php?event_id=24729




[CCPP-79] Assembly specification promotion mechanism
Created: 24/Jun/09  Updated: 17/Jul/09

Status: Closed
Project: OASIS SCA C-CPP TC
Component/s: C++ Public Review
Affects Version/s: Version 1.1
Fix Version/s: Version 1.1

Type: Bug Priority: Major
Reporter: Andrew Borley Assigned To: Bryan Aupperle
Resolution: No Action Votes: 0


 Description   
From posts to the sca-c-cpp-comment list:
http://lists.oasis-open.org/archives/sca-c-cpp-comment/200906/msg00000.html
http://lists.oasis-open.org/archives/sca-c-cpp-comment/200906/msg00002.html

The "promotion" mechanism described in Assembly specification, does not seem to be addressed here.

I guess I am a little confused about how the distinction between Composite and Component plays in the C++ implementation model:.
Do you consider "composite" as just an implementation concept only? (i.e. no dedicated class).
I see composite mentioned as a COmponent implementation "scope", so it seems it does not have a construct or class on its own.
If that is the case that should be more clearly stated, as in the Assembly mark-up it appears that a component is always used inside a Composite - and not by itself.
So that would also address my question about the "promotion" concept in Assembly that relates the Services of a composite to the Service of a component inside.
  

 Comments   
Comment by Andrew Borley [ 25/Jun/09 10:08 AM ]
Issue opened in SCA C and C++ Telcon Thursday, 25 June 2009.
See minutes at http://www.oasis-open.org/committees/event.php?event_id=19338
Comment by Andrew Borley [ 17/Jul/09 07:50 AM ]
Issue closed-no action in SCA C and C++ Telecon Thursday, 16 July 2009.
See minutes at http://www.oasis-open.org/committees/event.php?event_id=24729




[CCPP-78] PDF Formatting Issue
Created: 24/Jun/09  Updated: 17/Jul/09

Status: Closed
Project: OASIS SCA C-CPP TC
Component/s: C++ Public Review
Affects Version/s: Version 1.1
Fix Version/s: Version 1.1

Type: Bug Priority: Major
Reporter: Andrew Borley Assigned To: Bryan Aupperle
Resolution: No Action Votes: 0


 Description   
From posts to the sca-c-cpp-comment list:
http://lists.oasis-open.org/archives/sca-c-cpp-comment/200906/msg00000.html
http://lists.oasis-open.org/archives/sca-c-cpp-comment/200906/msg00002.html

In the PDF, title of section 6.4 seems to not be right (formatting issue?)
It looks like (in PDF) the table of contents is not uptodate: section 6.5 is announced as SCAExceptions, but it is actually 6.6.



 Comments   
Comment by Andrew Borley [ 25/Jun/09 10:07 AM ]
Issue opened in SCA C and C++ Telcon Thursday, 25 June 2009.
See minutes at http://www.oasis-open.org/committees/event.php?event_id=19338
Comment by Andrew Borley [ 17/Jul/09 07:50 AM ]
Issue closed-no action in SCA C and C++ Telecon Thursday, 16 July 2009.
See minutes at http://www.oasis-open.org/committees/event.php?event_id=24729




[CCPP-77] Make program-base component implementation support a separate conformance clause
Created: 19/Jun/09  Updated: 17/Feb/10

Status: Closed
Project: OASIS SCA C-CPP TC
Component/s: C Public Review
Affects Version/s: Version 1.1
Fix Version/s: Version 1.1

Type: Bug Priority: Major
Reporter: Andrew Borley Assigned To: Bryan Aupperle
Resolution: Fixed Votes: 0


 Description   
Target: C C&I Specification CD03 Rev 1 and Test Assertions WD08
 
Description:
The C C&I Specification provides for the optional support of program-based component implementations. This optional support results in a number of conformance points, and corresponding test assertions, that are not relevant if the support is not implemented. The other major optional capabilities have separate conformance clauses in section 11.2 with the corresponding conformance points separated into individual subsections of Appendix F. This is not the case for program-based component implementation support.
 
Proposal:
1) Add a conformance clause to section 11.2 stating that a conforming implementation MAY support program-based component implementations and that this requires supporting the corresponding additional API functions and relevant conformance points.
2) Remove C60003, as this is now covered by the new conformance clause
3) Move all of the conformance points that are specific to this support from the table in Appendix F to a corresponding table in a new subsection of appendix F.
4) Separate the test assertions for the conformance points that are specific to this support into separate, clearly identified subsections of the test assertions document.

Details to follow

Raised to the OASIS Service Component Architecture / C and C++ (SCA-C-C++) TC in the e-mail at http://lists.oasis-open.org/archives/sca-c-cpp/200906/msg00026.html

 Comments   
Comment by Andrew Borley [ 25/Jun/09 10:04 AM ]
Issue opened in SCA C and C++ Telcon Thursday, 25 June 2009.
See minutes at http://www.oasis-open.org/committees/event.php?event_id=19338
Comment by Andrew Borley [ 25/Jun/09 10:26 AM ]
Issue resolved in SCA C and C++ Telcon Thursday, 25 June 2009.
See minutes at http://www.oasis-open.org/committees/event.php?event_id=19338
Comment by Bryan Aupperle [ 17/Feb/10 08:54 AM ]
Included in CD04 (approved 21 Jan 2010).




[CCPP-76] Requirements on c:parameter/@type too lax
Created: 29/May/09  Updated: 17/Feb/10

Status: Closed
Project: OASIS SCA C-CPP TC
Component/s: C Public Review
Affects Version/s: Version 1.1
Fix Version/s: Version 1.1

Type: Bug Priority: Major
Reporter: Andrew Borley Assigned To: Bryan Aupperle
Resolution: Fixed Votes: 0


 Description   
Target: C C&I Specification CD03
 
Description:
The requirements on the c:parameter/@type attribute (Section D.6) are too lax, and allow specifying any valid C type. There isn’t enough information to support conversion to/from any arbitrary type.
 
Proposal:
 
Restrict the allowed types to those explicitly identified in the spec:
 
Â- type : string (0..1) â€" specifies the type of the parameter or struct member or return type. The @type attribute of a <c:parameter/> element MUST be a C type specified in section 10.3.1

Type needs to be a string since name and NCName do not allow '*'.

Raised to the OASIS Service Component Architecture / C and C++ (SCA-C-C++) TC in the e-mail at http://lists.oasis-open.org/archives/sca-c-cpp/200905/msg00025.html

 Comments   
Comment by Andrew Borley [ 04/Jun/09 10:04 AM ]
Issue opened in SCA C and C++ Telecon Thursday, 4 June 2009.
See minutes at http://www.oasis-open.org/committees/event.php?event_id=19335
Comment by Andrew Borley [ 11/Jun/09 10:11 AM ]
Issue resolved in SCA C and C++ Telecon Thursday, 11 June 2009.
See minutes at http://www.oasis-open.org/committees/event.php?event_id=19336
Comment by Bryan Aupperle [ 17/Feb/10 08:54 AM ]
Included in CD04 (approved 21 Jan 2010).




[CCPP-75] Review types supported in C Service interfaces
Created: 29/May/09  Updated: 17/Feb/10

Status: Closed
Project: OASIS SCA C-CPP TC
Component/s: C Public Review
Affects Version/s: Version 1.1
Fix Version/s: Version 1.1

Type: Bug Priority: Major
Reporter: Andrew Borley Assigned To: Bryan Aupperle
Resolution: Fixed Votes: 0


 Description   
Target: C C&I Specification CD03
 
Description:
The conformance items in section 8.1 and 8.2 are inconsistent with the WSDL mapping rules defined in section 10.3.
 
Proposal:
 
8.1 Local Services
 
The return type and types of parameters of a function of a local service MUST be one of:

    * Any fundamental or compound types as defined by C. [CPP80001]

 
8.2 Remotable Services
 
For a remotable service being called by another service the data exchange semantics is by-value. The return type and types of the parameters of a function of a remotable interface MUST be one of:

    * Any of the C types specified in Section 10.3.1 and 10.3.2. These types may be passed by-value or by-pointer. Unless the function and client indicate that they allow by-reference semantics (See Section 2.1.2), a copy will be explicitly created by the runtime for any parameters passed by-pointer.
    * An SDO DATAOBJECT. This type may be passed by-value or by-pointer. Unless the function and client indicate that they allow by-reference semantics (See Section 2.1.2), a copy will be explicitly created by the runtime for any parameters passed by-pointer. A deep-copy of the DATAOBJECT will be created by the runtime for any parameters passed by-value or by-pointer. [CPP80002]

Raised to the OASIS Service Component Architecture / C and C++ (SCA-C-C++) TC in the e-mail at http://lists.oasis-open.org/archives/sca-c-cpp/200905/msg00024.html

 Comments   
Comment by Andrew Borley [ 04/Jun/09 10:04 AM ]
Issue opened in SCA C and C++ Telecon Thursday, 4 June 2009.
See minutes at http://www.oasis-open.org/committees/event.php?event_id=19335
Comment by Andrew Borley [ 04/Jun/09 10:16 AM ]
Issue resolved in SCA C and C++ Telecon Thursday, 4 June 2009.
See minutes at http://www.oasis-open.org/committees/event.php?event_id=19335
Comment by Bryan Aupperle [ 17/Feb/10 08:54 AM ]
Included in CD04 (approved 21 Jan 2010).




[CCPP-74] Requirements on cpp:parameter/@type too lax
Created: 28/May/09  Updated: 17/Feb/10

Status: Closed
Project: OASIS SCA C-CPP TC
Component/s: C++ Public Review
Affects Version/s: Version 1.1
Fix Version/s: Version 1.1

Type: Bug Priority: Major
Reporter: Andrew Borley Assigned To: Bryan Aupperle
Resolution: Fixed Votes: 0


 Description   
Target: C++ C&I Specification CD03
 
Description:
The requirements on the cpp:parameter/@type attribute (Section D.6) are too lax, and allow specifying any valid C++ type. There isn't enough information to support conversion to/from any arbitrary type.
 
Proposal:
 
Restrict the allowed types to those explicitly identified in the spec:
 
- type : Name (0..1) - specifies the type of the parameter or struct member or return type. The @type attribute of a <cpp:parameter/> element MUST be a C++ type specified in section 10.3.1.
 
Rationale:
 
Since std::string is a valid type from section 10.3.1, the type of this attribute cannot be NCName. Switched to Name.
Since the default mapping is taken from this table, it seems to be a reasonable subset to choose the mapping from.

Raised to the OASIS Service Component Architecture / C and C++ (SCA-C-C++) TC in the e-mail at http://lists.oasis-open.org/archives/sca-c-cpp/200905/msg00017.html

 Comments   
Comment by Andrew Borley [ 29/May/09 07:35 AM ]
Issue opened in SCA C and C++ Telecon Thursday, 28 May 2009.
See minutes at http://www.oasis-open.org/committees/event.php?event_id=19334
Comment by Andrew Borley [ 29/May/09 07:35 AM ]
Issue resolved in SCA C and C++ Telecon Thursday, 28 May 2009.
See minutes at http://www.oasis-open.org/committees/event.php?event_id=19334
Comment by Bryan Aupperle [ 17/Feb/10 08:53 AM ]
Included in CD04 (approved 21 Jan 2010).




[CCPP-73] Review types supported in Service interfaces
Created: 28/May/09  Updated: 17/Feb/10

Status: Closed
Project: OASIS SCA C-CPP TC
Component/s: C++ Public Review
Affects Version/s: Version 1.1
Fix Version/s: Version 1.1

Type: Bug Priority: Major
Reporter: Andrew Borley Assigned To: Bryan Aupperle
Resolution: Fixed Votes: 0


 Description   
Target: C++ C&I Specification CD03
 

Description:

The conformance items in section 8.1 and 8.2 are inconsistent with the WSDL mapping rules defined in section 10.1.3.
 

Proposal:

8.1 Local Services

The return type and types of parameters of a member function of a local service MUST be one of:

    * Any fundamental or compound types as defined by C++. [CPP80001]

8.2 Remotable Services

For a remotable service being called by another service the data exchange semantics is by-value. The return type and types of the parameters of a member function of a remotable interface MUST be one of:

    * Any of the C++ types specified in Section 10.3.1. These types may be passed by-value, by-reference, or by-pointer. Unless the member function and client indicate that they allow by-reference semantics (See Section 2.1.2), copy will be explicitly created by the runtime for any parameters passed by-reference or by-pointer.
    * An SDO DataObjectPtr instance. This type may be passed by-value, by-reference, or by-pointer. Unless the member function and client indicate that they allow by-reference semantics (See Section 2.1.2), copy will be explicitly created by the runtime for any parameters passed by-reference or by-pointer, a deep-copy of the DataObjectPtr will be created by the runtime for any parameters passed by-value, by-reference, or by-pointer. [CPP80002]

Rationale:

    * Since a local service invoke is the equivalent of invoking the function directly, I'm not aware of any reasons why there should be any restrictions on the parameters of the function. For example, if we support passing a class instance, I'm not sure why we would not be able to support passing a union. If there are restrictions that the runtime should enforce, then additional clarifications will be needed.
    * Discussion of const/non-const doesn't seem relevant. There were no situations where we would allow passing a value if it was const, but not if it was non-const. const is a factor in determining the mapping of the parameters to/from WSDL types, however that is covered in a different section.

Raised to the OASIS Service Component Architecture / C and C++ (SCA-C-C++) TC in the e-mail at http://lists.oasis-open.org/archives/sca-c-cpp/200905/msg00016.html

 Comments   
Comment by Andrew Borley [ 29/May/09 07:35 AM ]
Issue opened in SCA C and C++ Telecon Thursday, 28 May 2009.
See minutes at http://www.oasis-open.org/committees/event.php?event_id=19334
Comment by Andrew Borley [ 29/May/09 07:36 AM ]
Issue resolved in SCA C and C++ Telecon Thursday, 28 May 2009.
See minutes at http://www.oasis-open.org/committees/event.php?event_id=19334
Comment by Bryan Aupperle [ 17/Feb/10 08:53 AM ]
Included in CD04 (approved 21 Jan 2010).




[CCPP-72] Use std::vector instead of std::list for multi-target references.
Created: 22/Apr/09  Updated: 17/Feb/10

Status: Closed
Project: OASIS SCA C-CPP TC
Component/s: C++ Public Review
Affects Version/s: Version 1.1
Fix Version/s: Version 1.1

Type: Bug Priority: Major
Reporter: Andrew Borley Assigned To: Bryan Aupperle
Resolution: Fixed Votes: 0


 Description   
Target: C++ C&I Specification CD03

Description:
The getServices and getServiceReferences member functions of the ComponentContext class return std::lists. Given that the size of this lists will not vary once created by the member function call, it would be more appropriate for these member functions to return std::vectors. The resulting code, client and infrastructure, would be more efficient and the client code would be simpler - it would not be necessary to use itterators.

Proposal:
Change the return types of these two member functions to use std::vector instead of std::list. A corresponding change in the description of @Reference is also needed.

Raised to the OASIS Service Component Architecture / C and C++ (SCA-C-C++) TC in the e-mail at http://lists.oasis-open.org/archives/sca-c-cpp/200904/msg00043.html

 Comments   
Comment by Andrew Borley [ 24/Apr/09 03:00 AM ]
Issue opened in SCA C and C++ Telecon Thursday, 23 Apr 2009.
See minutes at http://www.oasis-open.org/committees/event.php?event_id=19329
Comment by Andrew Borley [ 24/Apr/09 03:02 AM ]
Issue resolved in SCA C and C++ Telecon Thursday, 23 Apr 2009.
See minutes at http://www.oasis-open.org/committees/event.php?event_id=19329
Comment by Bryan Aupperle [ 17/Feb/10 08:53 AM ]
Included in CD04 (approved 21 Jan 2010).




[CCPP-71] C Conformance text corrections
Created: 22/Apr/09  Updated: 17/Feb/10

Status: Closed
Project: OASIS SCA C-CPP TC
Component/s: C Public Review
Affects Version/s: Version 1.1
Fix Version/s: Version 1.1

Type: Bug Priority: Major
Reporter: Andrew Borley Assigned To: Bryan Aupperle
Resolution: Fixed Votes: 0


 Description   
Target: C C&I Specification CD03

Description:
1) OASIS guidelines require more specificity in our conformance clauses about MUST conformance points having to be implemented.
2) The conformance points for major options sections are combined with mandatory sections, This makes the conformance clauses confusing and contradictory.
3) There are MAY statements in section A.4 and D.7 that are not included in conformance points.

Proposal:
1) Add the phrase "notably all mandatory statements have to be implemented|supported" to conformance clauses referring to conformance points.
2) Split the conformance points in appendix F for the appendices into subsections for annotations and WSDL extension conformance points and make corresponding changes in the conformance clauses discussing annotations and WSDL extensions,
3) Convert the statements in A.4 and D.7 into conformance points.

Raised to the OASIS Service Component Architecture / C and C++ (SCA-C-C++) TC in the e-mail at http://lists.oasis-open.org/archives/sca-c-cpp/200904/msg00041.html

 Comments   
Comment by Andrew Borley [ 24/Apr/09 03:00 AM ]
Issue opened in SCA C and C++ Telecon Thursday, 23 Apr 2009.
See minutes at http://www.oasis-open.org/committees/event.php?event_id=19329
Comment by Andrew Borley [ 30/Apr/09 10:28 AM ]
Issue resolved in SCA C and C++ Telecon Thursday, 30 Apr 2009.
See minutes at http://www.oasis-open.org/committees/event.php?event_id=19330
Comment by Bryan Aupperle [ 17/Feb/10 08:53 AM ]
Included in CD04 (approved 21 Jan 2010).




[CCPP-70] C++ Conformance text corrections
Created: 22/Apr/09  Updated: 17/Feb/10

Status: Closed
Project: OASIS SCA C-CPP TC
Component/s: C++ Public Review
Affects Version/s: Version 1.1
Fix Version/s: Version 1.1

Type: Bug Priority: Major
Reporter: Andrew Borley Assigned To: Bryan Aupperle
Resolution: Fixed Votes: 0


 Description   
Target: C++ C&I Specification CD03

Description:
1) OASIS guidelines require more specificity in our conformance clauses about MUST conformance points having to be implemented.
2) The conformance points for major options sections are combined with mandatory sections, This makes the conformance clauses confusing and contradictory.
3) There is a MAY statement in section D.7 that is not included in a conformance point.

Proposal:
1) Add the phrase "notably all mandatory statements have to be implemented|supported" to conformance clauses referring to conformance points.
2) Split the conformance points in appendix F for the appendices into subsections for annotations and WSDL extension conformance points and make corresponding changes in the conformance clauses discussing annotations and WSDL extensions,
3) Convert the statement in D.7 into a conformance point.


Raised to the OASIS Service Component Architecture / C and C++ (SCA-C-C++) TC in the e-mail at http://lists.oasis-open.org/archives/sca-c-cpp/200904/msg00042.html

 Comments   
Comment by Andrew Borley [ 24/Apr/09 02:59 AM ]
Issue opened in SCA C and C++ Telecon Thursday, 23 Apr 2009.
See minutes at http://www.oasis-open.org/committees/event.php?event_id=19329
Comment by Andrew Borley [ 30/Apr/09 10:28 AM ]
Issue resolved in SCA C and C++ Telecon Thursday, 30 Apr 2009.
See minutes at http://www.oasis-open.org/committees/event.php?event_id=19330
Comment by Bryan Aupperle [ 17/Feb/10 08:53 AM ]
Included in CD04 (approved 21 Jan 2010).




[CCPP-69] C++ componentType schema missing definitions in normativesection
Created: 14/Apr/09  Updated: 17/Feb/10

Status: Closed
Project: OASIS SCA C-CPP TC
Component/s: C++ Public Review
Affects Version/s: Version 1.1
Fix Version/s: Version 1.1

Type: Bug Priority: Major
Reporter: Andrew Borley Assigned To: Bryan Aupperle
Resolution: Fixed Votes: 0


 Description   
Target: C++ C&I Specification CD03

Description:
1) Section 2.4.1 of the C++ C&I specification contains the normative definition of <interface.cpp/> but it does not describe the @requires and @policySets attributes that apply to this element as defined in the core SCA schema.
2) An @policySets attributes needs to be added to the definition of <function/> and <callbackFunction/> in Section 2.4.2 of the C++ C&I specification (as well as the interface.cpp schema).
3) Section 2.4.3 of the C++ C&I specification contains the normative definition of <implementation.cpp/> but it does not describe the @requires and @policySets attributes that apply to this element as defined in the core SCA schema.
4) An @policySets attributes needs to be added to the definition of <function/> in Section 2.4.4 of the C++ C&I specification (as well as the implementation.cpp schema).

Proposal:
1) In section 2.4.1, add @requires and @policySets to the pseudo-schema for <interface.cpp/> and descriptions using language consistent with samples found in the assembly specification. In particular, it should be noted that intents on an interface adds to or qualifies the intents of an individual member function of that interface.
2) In section 2.4.2 add @policySets to the pseudo-schema shared by <function/> and <callbackFunction/>and a description using language consistent with samples found in the assembly specification. Also add this attribute to the CPPFunction in the interface.cpp schema.
3) In section 2.4.3, add @requires and @policySets to the pseudo-schema for <implementation.cpp/> and descriptions using language consistent with samples found in the assembly specification. In particular, it should be noted that intents on an implementation adds to or qualifies the intents of an individual member function of that implementation.
4) In section 2.4.4 add @policySets to the pseudo-schema for <function/> and a description using language consistent with samples found in the assembly specification. Also add this attribute to the CPPImplementationFunction in the implementation.cpp schema.

Raised to the OASIS Service Component Architecture / C and C++ (SCA-C-C++) TC in the e-mail at http://lists.oasis-open.org/archives/sca-c-cpp/200904/msg00027.html

 Comments   
Comment by Andrew Borley [ 16/Apr/09 10:40 AM ]
Issue opened in SCA C and C++ Telecon Thursday, 16 Apr 2009.
See minutes at http://www.oasis-open.org/committees/event.php?event_id=19328
Comment by Andrew Borley [ 24/Apr/09 03:01 AM ]
Issue resolved in SCA C and C++ Telecon Thursday, 23 Apr 2009.
See minutes at http://www.oasis-open.org/committees/event.php?event_id=19329
Comment by Bryan Aupperle [ 17/Feb/10 08:53 AM ]
Included in CD04 (approved 21 Jan 2010).




[CCPP-68] C componentType schema missing definitions in normative section
Created: 14/Apr/09  Updated: 17/Feb/10

Status: Closed
Project: OASIS SCA C-CPP TC
Component/s: C Public Review
Affects Version/s: Version 1.1
Fix Version/s: Version 1.1

Type: Bug Priority: Major
Reporter: Andrew Borley Assigned To: Bryan Aupperle
Resolution: Fixed Votes: 0


 Description   
Target: C C&I Specification CD03

Description:
1) Section 2.4.1 of the C C&I specification contains the normative definition of <interface.c/> but it does not describe the @requires and @policySets attributes that apply to this element as defined in the core SCA schema.
2) An @policySets attributes needs to be added to the definition of <function/> and <callbackFunction/> in Section 2.4.2 of the C C&I specification (as well as the interface.c schema).
3) Section 2.4.3 of the C C&I specification contains the normative definition of <implementation.c/> but it does not describe the @requires and @policySets attributes that apply to this element as defined in the core SCA schema.
4) An @policySets attributes needs to be added to the definition of <function/> in Section 2.4.4 of the C C&I specification (as well as the implementation.c schema).

Proposal:
1) In section 2.4.1, add @requires and @policySets to the pseudo-schema for <interface.c/> and descriptions using language consistent with samples found in the assembly specification. In particular, it should be noted that intents on an interface adds to or qualifies the intents of an individual function of that interface.

Raised to the OASIS Service Component Architecture / C and C++ (SCA-C-C++) TC in the e-mail at http://lists.oasis-open.org/archives/sca-c-cpp/200904/msg00028.html
2) In section 2.4.2 add @policySets to the pseudo-schema shared by <function/> and <callbackFunction/>and a description using language consistent with samples found in the assembly specification. Also add this attribute to the CFunction in the interface.c schema.
3) In section 2.4.3, add @requires and @policySets to the pseudo-schema for <implementation.c/> and descriptions using language consistent with samples found in the assembly specification. In particular, it should be noted that intents on an implementation adds to or qualifies the intents of an individual member function of that implementation.
4) In section 2.4.4 add @policySets to the pseudo-schema for <function/> and a description using language consistent with samples found in the assembly specification. Also add this attribute to the CImplementationFunction in the implementation.c schema

Raised to the OASIS Service Component Architecture / C and C++ (SCA-C-C++) TC in the e-mail at http://lists.oasis-open.org/archives/sca-c-cpp/200904/msg00028.html

 Comments   
Comment by Andrew Borley [ 16/Apr/09 10:40 AM ]
Issue opened in SCA C and C++ Telecon Thursday, 16 Apr 2009.
See minutes at http://www.oasis-open.org/committees/event.php?event_id=19328
Comment by Andrew Borley [ 24/Apr/09 03:01 AM ]
Issue resolved in SCA C and C++ Telecon Thursday, 23 Apr 2009.
See minutes at http://www.oasis-open.org/committees/event.php?event_id=19329
Comment by Bryan Aupperle [ 17/Feb/10 08:52 AM ]
Included in CD04 (approved 21 Jan 2010).




[CCPP-67] C++ Conformance wording changes regarding external files
Created: 14/Apr/09  Updated: 17/Feb/10

Status: Closed
Project: OASIS SCA C-CPP TC
Component/s: C++ Public Review
Affects Version/s: Version 1.1
Fix Version/s: Version 1.1

Type: Bug Priority: Major
Reporter: Andrew Borley Assigned To: Bryan Aupperle
Resolution: Fixed Votes: 0


 Description   
Target: C++ C&I Specification CD03

Description:
1) The statements in Appendices D and E about the external schema being authoritative over the copies in the appendices need to be moved to section 11.
2) A statement needs to be added to section 11 that the specification text concerning the API definition is authoritative over any code files related to the specification.

Proposal:
1) Move statements regarding authoritative schema from top of sections D.8 and E to top of section 11.
2) Add statement in section 11 indicating that API definitions in specification are authoritative over any code files.

Raised to the OASIS Service Component Architecture / C and C++ (SCA-C-C++) TC in the e-mail at http://lists.oasis-open.org/archives/sca-c-cpp/200904/msg00020.html

 Comments   
Comment by Andrew Borley [ 16/Apr/09 10:39 AM ]
Issue opened in SCA C and C++ Telecon Thursday, 16 Apr 2009.
See minutes at http://www.oasis-open.org/committees/event.php?event_id=19328
Comment by Andrew Borley [ 16/Apr/09 10:41 AM ]
Issue resolved in SCA C and C++ Telecon Thursday, 16 Apr 2009.
See minutes at http://www.oasis-open.org/committees/event.php?event_id=19328
Comment by Bryan Aupperle [ 17/Feb/10 08:52 AM ]
Included in CD04 (approved 21 Jan 2010).




[CCPP-66] C Conformance wording changes regarding external files
Created: 14/Apr/09  Updated: 17/Feb/10

Status: Closed
Project: OASIS SCA C-CPP TC
Component/s: C Public Review
Affects Version/s: Version 1.1
Fix Version/s: Version 1.1

Type: Bug Priority: Major
Reporter: Andrew Borley Assigned To: Bryan Aupperle
Resolution: Fixed Votes: 0


 Description   
Target: C C&I Specification CD03

Description:
1) The statements in Appendices D and E about the external schema being authoritative over the copies in the appendices need to be moved to section 11.
2) A statement needs to be added to section 11 that the specification text concerning the API definition is authoritative over any code files related to the specification.

Proposal:
1) Move statements regarding authoritative schema from top of sections D.8 and E to top of section 11.
2) Add statement in section 11 indicating that API definitions in specification are authoritative over any code files.

Raised to the OASIS Service Component Architecture / C and C++ (SCA-C-C++) TC in the e-mail at http://lists.oasis-open.org/archives/sca-c-cpp/200904/msg00021.html

 Comments   
Comment by Andrew Borley [ 16/Apr/09 10:38 AM ]
Issue opened in SCA C and C++ Telecon Thursday, 16 Apr 2009.
See minutes at http://www.oasis-open.org/committees/event.php?event_id=19328
Comment by Andrew Borley [ 16/Apr/09 10:40 AM ]
Issue resolved in SCA C and C++ Telecon Thursday, 16 Apr 2009.
See minutes at http://www.oasis-open.org/committees/event.php?event_id=19328
Comment by Bryan Aupperle [ 17/Feb/10 08:52 AM ]
Included in CD04 (approved 21 Jan 2010).




[CCPP-65] C++ C&I is inconsistent wrt Policy
Created: 30/Mar/09  Updated: 17/Feb/10

Status: Closed
Project: OASIS SCA C-CPP TC
Component/s: C++ Public Review
Affects Version/s: Version 1.1
Fix Version/s: Version 1.1

Type: Bug Priority: Major
Reporter: Andrew Borley Assigned To: Bryan Aupperle
Resolution: Fixed Votes: 0


 Description   
Target: C++ C&I Specification CD03

Description: The specific intent annotations defined in Appendix B.2 are not consistent with the intents defined in Public Review Draft of the SCA Policy Framework spec. Specifically
1) The Policy Framework now defines intents for clientAuthentication, serverAuthentication and mutualAuthentication (the original authentication intent remains, but is a synonym for clientAuthentication)
2) Replaced all the prior Security Implementation intents with a single authentication intent, which can be qualified with fine_grain.
3) Added a noManagedTransaction intent (which has different semantics that a lack of a managedTransaction intent).

Proposal: (All changes are in section B.2)
1) Replace @Authentication with @Client Authentication and add @ServerAuthentication and @MutualAuthentication intents, both of which can be qualified with message or transport
2) Remove all of the current Security Implementation intent annotations and add an @Authorization intent, which can be qualified with fine_grain
3) Ann a @NoManagedTransaction intent
4) Remove the @JMS annotation since a C++ application is unlikely to use the JMS API.

Raised to the OASIS Service Component Architecture / C and C++ (SCA-C-C++) TC in the e-mail at http://lists.oasis-open.org/archives/sca-c-cpp/200903/msg00064.html

 Comments   
Comment by Andrew Borley [ 09/Apr/09 11:15 AM ]
Issue opened in SCA C and C++ Telecon Thursday, 9 Apr 2009.
See minutes at http://www.oasis-open.org/committees/event.php?event_id=19327
Comment by Andrew Borley [ 09/Apr/09 11:15 AM ]
Issue resolved in SCA C and C++ Telecon Thursday, 9 Apr 2009.
See minutes at http://www.oasis-open.org/committees/event.php?event_id=19327
Comment by Bryan Aupperle [ 17/Feb/10 08:51 AM ]
Included in CD04 (approved 21 Jan 2010).




[CCPP-64] C C&I is inconsistent wrt Policy
Created: 30/Mar/09  Updated: 17/Feb/10

Status: Closed
Project: OASIS SCA C-CPP TC
Component/s: C Public Review
Affects Version/s: Version 1.1
Fix Version/s: Version 1.1

Type: Bug Priority: Major
Reporter: Andrew Borley Assigned To: Bryan Aupperle
Resolution: Fixed Votes: 0


 Description   
Target: C C&I Specification CD03

Description: The specific intent annotations defined in Appendix B.2 are not consistent with the intents defined in Public Review Draft of the SCA Policy Framework spec. Specifically
1) The Policy Framework now defines intents for clientAuthentication, serverAuthentication and mutualAuthentication (the original authentication intent remains, but is a synonym for clientAuthentication)
2) Replaced all the prior Security Implementation intents with a single authentication intent, which can be qualified with fine_grain.
3) Added a noManagedTransaction intent (which has different semantics that a lack of a managedTransaction intent).

Proposal: (All changes are in section B.2)
1) Replace @Authentication with @Client Authentication and add @ServerAuthentication and @MutualAuthentication intents, both of which can be qualified with message or transport
2) Remove all of the current Security Implementation intent annotations and add an @Authorization intent, which can be qualified with fine_grain
3) Ann a @NoManagedTransaction intent
4) Remove the @JMS annotation since a C application is unlikely to use the JMS API.

Raised to the OASIS Service Component Architecture / C and C++ (SCA-C-C++) TC in the e-mail at http://lists.oasis-open.org/archives/sca-c-cpp/200903/msg00065.html

 Comments   
Comment by Andrew Borley [ 09/Apr/09 11:14 AM ]
Issue opened in SCA C and C++ Telecon Thursday, 9 Apr 2009.
See minutes at http://www.oasis-open.org/committees/event.php?event_id=19327
Comment by Andrew Borley [ 09/Apr/09 11:14 AM ]
Issue resolved in SCA C and C++ Telecon Thursday, 9 Apr 2009.
See minutes at http://www.oasis-open.org/committees/event.php?event_id=19327
Comment by Bryan Aupperle [ 17/Feb/10 08:51 AM ]
Included in CD04 (approved 21 Jan 2010).




[CCPP-63] CPPF0038 is incorrect
Created: 29/Mar/09  Updated: 17/Feb/10

Status: Closed
Project: OASIS SCA C-CPP TC
Component/s: C++ Public Review
Affects Version/s: Version 1.1
Fix Version/s: Version 1.1

Type: Bug Priority: Major
Reporter: Andrew Borley Assigned To: Bryan Aupperle
Resolution: Fixed Votes: 0


 Description   
Target: C++ C&I Specification CD03

Description: CPPF0038 is a application of a conformance point from JAX-WS dealing with the default naming of exceptions. Because of the differences in exceptions in C++ and Java, this conformance point of JAX-WS does not apply to C++.

Proposal:
1) Remove CPPF0038 and move the Exception Naming entry to the table in F.1.1
2) Add the following to section 10.2.4. (After the sentence that ends on line 1559)

By default, no exceptions are mapped to operation faults.

Raised to the OASIS Service Component Architecture / C and C++ (SCA-C-C++) TC in the e-mail at http://lists.oasis-open.org/archives/sca-c-cpp/200903/msg00061.html


 Comments   
Comment by Andrew Borley [ 09/Apr/09 11:13 AM ]
Issue opened in SCA C and C++ Telecon Thursday, 9 Apr 2009.
See minutes at http://www.oasis-open.org/committees/event.php?event_id=19327
Comment by Andrew Borley [ 09/Apr/09 11:13 AM ]
Issue resolved in SCA C and C++ Telecon Thursday, 9 Apr 2009.
See minutes at http://www.oasis-open.org/committees/event.php?event_id=19327
Comment by Bryan Aupperle [ 17/Feb/10 08:51 AM ]
Included in CD04 (approved 21 Jan 2010).




[CCPP-62] C API description errors
Created: 29/Mar/09  Updated: 17/Feb/10

Status: Closed
Project: OASIS SCA C-CPP TC
Component/s: C Public Review
Affects Version/s: Version 1.1
Fix Version/s: Version 1.1

Type: Bug Priority: Major
Reporter: Andrew Borley Assigned To: Bryan Aupperle
Resolution: Fixed Votes: 0


 Description   
Target: C C&I Specification CD03

Description: There are some typos in the C API description:

1) Declaration of SCAInvokeAsync: void (*handler)(short); should be void (*handler)(short), the ";" should be a ",". (line 1120)
2) Declaration of SCACheckResponse: there should be a "," after responseType. (line 1132)
3) Description of SCAGetFaultMessage: description of reason is missing a "not", i.e. "if the last operation invoked on the Reference did return a business fault" should be "if the last operation invoked on the Reference did not return a business fault" (Section 6.1.6)
4) Descriptions of SCAInvoke and SCAGetFaultMessage: incorrect capitalization of some parameter names. (Sections 6.1.3 and 6.1.6)

Proposal: As per description.

Raised to the OASIS Service Component Architecture / C and C++ (SCA-C-C++) TC in the e-mail at http://lists.oasis-open.org/archives/sca-c-cpp/200903/msg00060.html

 Comments   
Comment by Andrew Borley [ 09/Apr/09 11:11 AM ]
Issue opened in SCA C and C++ Telecon Thursday, 9 Apr 2009.
See minutes at http://www.oasis-open.org/committees/event.php?event_id=19327
Comment by Andrew Borley [ 09/Apr/09 11:12 AM ]
Issue resolved in SCA C and C++ Telecon Thursday, 9 Apr 2009.
See minutes at http://www.oasis-open.org/committees/event.php?event_id=19327
Comment by Bryan Aupperle [ 17/Feb/10 08:51 AM ]
Included in CD04 (approved 21 Jan 2010).




[CCPP-61] Conformance text cleanup
Created: 03/Mar/09  Updated: 26/Mar/09

Status: Closed
Project: OASIS SCA C-CPP TC
Component/s: C specification, C++ specification
Affects Version/s: Version 1.1
Fix Version/s: Version 1.1

Type: Bug Priority: Major
Reporter: Andrew Borley Assigned To: Bryan Aupperle
Resolution: Fixed Votes: 0


 Description   
Target: C++ and C C&I Specifications

Description: The Assembly TC has finalized the conformance text for the Assembly spec. There are some corresponding changes needed in the C++ C C&I specifications. Specifically:

1) Statements that an SCA implementation must reject files that do not conform to the SCA schema for [C++|C].
2) Elimination of the duplication of the broad MUST statements in the Conformance section about API implementation and Annotation/WSDL extension support and similar Statements in Chapter 6 and Appendices A, C, and D.
3) References in the Conformance Section to the statements in Appendix F
4) Break out the details for document conformance for each of Composite, ComponentType, ConstrainingType and Contribution

Proposal: To follow.

Raised to the OASIS Service Component Architecture / C and C++ (SCA-C-C++) TC in the e-mail at http://lists.oasis-open.org/archives/sca-c-cpp/200903/msg00001.html

 Comments   
Comment by Bryan Aupperle [ 05/Mar/09 01:27 PM ]
Issue openedin SCA C and C++ Telecon Thursday, 5 Mar2009.
See minutes at http://www.oasis-open.org/committees/event.php?event_id=19322
Comment by Andrew Borley [ 13/Mar/09 04:06 AM ]
Issue resolved in SCA C and C++ Telecon Thursday, 12 Mar 2009.
See minutes at http://www.oasis-open.org/committees/event.php?event_id=19323
Comment by Bryan Aupperle [ 26/Mar/09 08:42 AM ]
Issue closed in Committee Draft 03. Approved in in SCA C and C++ Telecon Thursday, 19 March 2009.
See minutes at http://www.oasis-open.org/committees/event.php?event_id=19324




[CCPP-60] Policy and Assembly have removed operation element from Service and Reference
Created: 17/Feb/09  Updated: 26/Mar/09

Status: Closed
Project: OASIS SCA C-CPP TC
Component/s: C specification, C++ specification
Affects Version/s: Version 1.1
Fix Version/s: Version 1.1

Type: Bug Priority: Major
Reporter: Andrew Borley Assigned To: Bryan Aupperle
Resolution: Fixed Votes: 0


 Description   
Target: C++ and C C&I Specification

Description: The Assembly TC has, in reaction to a decision in the Policy TC, removed the operation element from Service and Reference. The primary impact of this is that there is no mechanism in SCDL to attach an intent to an operation unless it is done so in the interface document itself. (PolicySets can still be attached to operations via an external attachment mechanism - in the policySet definition itself). The current C++ and C specs allow intents to be attached, via annotations to individual (member) functions and data members/variables. Further, the formal definitions of the intents defined by the Policy spec indicate that they constrain bindings or implementations.

Proposal:

We have two options

1) Add a requires attribute to function and callbackFunction and remove the ability for intent and policySets annotations to apply to data members/variables

2) Only allow intent annotations to apply to classes/sets of functions defining an interface & sets of functions defining an implementation and remove the ability for policySets annotations to apply to data members/variables.

Raised to the OASIS Service Component Architecture / C and C++ (SCA-C-C++) TC in the e-mail at http://lists.oasis-open.org/archives/sca-c-cpp/200902/msg00037.html

 Comments   
Comment by Andrew Borley [ 19/Feb/09 10:11 AM ]
Opened in SCA C and C++ Telecon Thursday, 19th February 2009
See minutes at http://www.oasis-open.org/committees/event.php?event_id=19320
Comment by Andrew Borley [ 27/Feb/09 03:17 AM ]
Resolved in SCA C and C++ Telecon Thursday, 26th February 2009
See minutes at http://www.oasis-open.org/committees/event.php?event_id=19321

Comment by Bryan Aupperle [ 26/Mar/09 08:42 AM ]
Issue closed in Committee Draft 03. Approved in in SCA C and C++ Telecon Thursday, 19 March 2009.
See minutes at http://www.oasis-open.org/committees/event.php?event_id=19324




[CCPP-59] AllowsPassByReference requires more detailed description
Created: 04/Feb/09  Updated: 26/Mar/09

Status: Closed
Project: OASIS SCA C-CPP TC
Component/s: C specification, C++ specification
Affects Version/s: Version 1.1
Fix Version/s: Version 1.1

Type: Bug Priority: Major
Reporter: Andrew Borley Assigned To: Bryan Aupperle
Resolution: Fixed Votes: 0


 Description   
TARGET:

C++ and C C&I specifications

DESCRIPTION:

Currently the specification only states the requirement that the callee must adhere to by-value semantics when indicating that a remotable interface or function of a remotable interface allows the optimization of by-reference parameter passing.

It lacks a descriptions of requirements on the caller to not modify a passed by-reference parameter during the execution of an AllowsPassByReference function. Such concurrency situations may occur for example when

a) the caller is inherently multi-threaded and holds-on to parameters in concurrently executed threads
b) the caller is called back during an invocation of an AllowsPassByReference function(which can happen in the same thread)
c) the AllowsPassByReference method is in addition a OneWay function(i.e. the caller will not wait for the completion of the actual service method)

PROPOSAL:

Discussion currently underway in the Java TC, but the key aspect is that a client implementation must also be marked AllowsPassByReference. We would need to decide how to apply this approach to both C++ and C.

Raised to the OASIS Service Component Architecture / C and C++ (SCA-C-C++) TC in the e-mail at http://lists.oasis-open.org/archives/sca-c-cpp/200902/msg00007.html

 Comments   
Comment by Andrew Borley [ 05/Feb/09 10:14 AM ]
Opened in SCA C and C++ Telecon Thursday, 5th February 2009
See minutes at http://www.oasis-open.org/committees/event.php?event_id=19318
Comment by Andrew Borley [ 27/Feb/09 03:17 AM ]
Resolved in SCA C and C++ Telecon Thursday, 26th February 2009
See minutes at http://www.oasis-open.org/committees/event.php?event_id=19321
Comment by Bryan Aupperle [ 26/Mar/09 08:42 AM ]
Issue closed in Committee Draft 03. Approved in in SCA C and C++ Telecon Thursday, 19 March 2009.
See minutes at http://www.oasis-open.org/committees/event.php?event_id=19324




[CCPP-58] Type Mappings not Defined by SDO
Created: 03/Feb/09  Updated: 26/Mar/09

Status: Closed
Project: OASIS SCA C-CPP TC
Component/s: C specification, C++ specification
Affects Version/s: Version 1.1
Fix Version/s: Version 1.1

Type: Bug Priority: Major
Reporter: Andrew Borley Assigned To: Bryan Aupperle
Resolution: Fixed Votes: 0


 Description   
Target: C++ and C specification CD01-Rev4

Description: Our current type mapping is based on those defined by SDO 2.1. This leaves several mappings undefined. For example: xsd:decimal or xsd:anySImpleType have no mapping to SDO types in C++ or C. And in the reverse direction of this no define mapping for common C++ and C type like long.

Proposal: Needs discussion.

Raised to the OASIS Service Component Architecture / C and C++ (SCA-C-C++) TC in the e-mail at http://lists.oasis-open.org/archives/sca-c-cpp/200902/msg00003.html

 Comments   
Comment by Andrew Borley [ 05/Feb/09 10:14 AM ]
Opened in SCA C and C++ Telecon Thursday, 5th February 2009
See minutes at http://www.oasis-open.org/committees/event.php?event_id=19318
Comment by Andrew Borley [ 19/Feb/09 10:13 AM ]
Resolved in SCA C and C++ Telecon Thursday, 19th February 2009
See minutes at http://www.oasis-open.org/committees/event.php?event_id=19320
Comment by Bryan Aupperle [ 26/Mar/09 08:42 AM ]
Issue closed in Committee Draft 03. Approved in in SCA C and C++ Telecon Thursday, 19 March 2009.
See minutes at http://www.oasis-open.org/committees/event.php?event_id=19324




[CCPP-57] Callback Simplification
Created: 27/Jan/09  Updated: 05/Mar/09

Status: Closed
Project: OASIS SCA C-CPP TC
Component/s: C specification, C++ specification
Affects Version/s: Version 1.1
Fix Version/s: Version 1.1

Type: Bug Priority: Major
Reporter: Andrew Borley Assigned To: Bryan Aupperle
Resolution: Fixed Votes: 0


 Description   
Target: C++ and C C&I specifications

Description: The Java TC has passed a resolution to simplify the programming model for callbacks. Specifically they removed the capability for getting/setting the Callback ID and setting the callback object handler (which we have already done base on Assembly TC action). They have also reworked some examples.

Proposal:
The section Stateless Callbacks needs to be revised. (Both Specs)
The section Customizing the Callback Identity needs to be removed (Both Specs)
The NoRegisteredCallback exception needs to be removed (C++ only)
The getCallbackID() and setCallbackID() member functions need to be removed from ServiceReference (C++ only)
The SCA_NO_REGISTERED_CALLBACK reason code needs to be removed (C only)
The SCAGetCallbackID() and SCASetCallbackID() functions need to be removed (C only)

Raised to the OASIS Service Component Architecture / C and C++ (SCA-C-C++) TC in the e-mail at http://lists.oasis-open.org/archives/sca-c-cpp/200901/msg00031.html

 Comments   
Comment by Andrew Borley [ 29/Jan/09 10:06 AM ]
Opened in SCA C and C++ Telecon Thursday, 29th January 2009
See minutes at http://www.oasis-open.org/committees/event.php?event_id=19317
Comment by Andrew Borley [ 29/Jan/09 10:50 AM ]
Resolved in SCA C and C++ Telecon Thursday, 29th January 2009
See minutes at http://www.oasis-open.org/committees/event.php?event_id=19317
Comment by Bryan Aupperle [ 05/Mar/09 01:21 PM ]
Issue closed in Committee Draft 02. Approved in in SCA C and C++ Telecon Thursday, 5 February 2009.
See minutes at http://www.oasis-open.org/committees/event.php?event_id=19318




[CCPP-56] Remove conversational interface support
Created: 21/Jan/09  Updated: 05/Mar/09

Status: Closed
Project: OASIS SCA C-CPP TC
Component/s: C specification, C++ specification
Affects Version/s: Version 1.1
Fix Version/s: Version 1.1

Type: Bug Priority: Major
Reporter: Andrew Borley Assigned To: Bryan Aupperle
Resolution: Fixed Votes: 0


 Description   
Target: C++ and C C&I specifications

Description: The assembly TC has removed conversational interfaces from SCA 1.1. We need to make corresponding changes.

Proposal:

1) Remove the @Conversational and @EndsConversation annotations (Sections A.2.5 and A.2.6 for C++, sections A.2.6 and A.2.7 for C. and references in B.2 in each spec)
2) Remove the endsConversation attribute of the function and callbackFunction child elements of interface.cpp and interface.c (section 2.5.2 of both specification) and the schema.
3) Remove API support for getting and setting conversation IDs and ending conversations (sections 7.3.2, 7.3.3, and 7.3.7 for C++, all of section 7.4 for C).
4) Remove conversation specific exceptions/error codes (sections 7.9, 7.11, and 7.12 for C++, SCA_CONVERSATION_ENDED for C).
5) Remove chapter 4 from each specification
6) Remove conversation scope (section 2.3.3 in each spec, with corresponding changes to @Scope, and the schema)
7) Remove @ConversationAttributes (section A.3.5 for C++ and A.3.10 for C)
8) Remove the conversationMaxAge, conversationMaxIdle and conversationSinglePrincipal attributes from inplemenation,cpp and implementation.c (sections 2.5.3 of each spec) and the schema

Raised to the OASIS Service Component Architecture / C and C++ (SCA-C-C++) TC in the e-mail at http://lists.oasis-open.org/archives/sca-c-cpp/200901/msg00018.html

 Comments   
Comment by Andrew Borley [ 22/Jan/09 10:05 AM ]
Opened in SCA C and C++ Telecon Thursday, 22nd January 2009
See minutes at http://www.oasis-open.org/committees/event.php?event_id=19316
Comment by Andrew Borley [ 29/Jan/09 10:41 AM ]
Resolved in SCA C and C++ Telecon Thursday, 29th January 2009
See minutes at http://www.oasis-open.org/committees/event.php?event_id=19317
Comment by Bryan Aupperle [ 05/Mar/09 01:21 PM ]
Issue closed in Committee Draft 02. Approved in in SCA C and C++ Telecon Thursday, 5 February 2009.
See minutes at http://www.oasis-open.org/committees/event.php?event_id=19318




[CCPP-55] C Support for Long Running Request-Response Operations
Created: 10/Dec/08  Updated: 26/Mar/09

Status: Closed
Project: OASIS SCA C-CPP TC
Component/s: C specification
Affects Version/s: Version 1.1
Fix Version/s: Version 1.1

Type: Bug Priority: Major
Reporter: Andrew Borley Assigned To: Bryan Aupperle
Resolution: Fixed Votes: 0


 Description   
Target: C Client and Implementation Specification

Description: The Assembly TC has resolved http://www.osoa.org/jira/browse/ASSEMBLY-33 which points out that some services may implement request-response operations that may take a considerable time (think potentially days) to complete. The resolution is found in this document: .

We need to consider what, if any, support we which to add for this sort of operation.

On the implementation side, do we want to allow interfaces or functions to be marked as this type of service?

On the client side, do we want to provide either asynchronous or polling functions for these sorts of operations (we could force the binding to deal with the asynchronous nature of the response, but this could leave threads blocked for a long time).

Proposal:
TBD

Raised to the OASIS Service Component Architecture / C and C++ (SCA-C-C++) TC in the e-mail at http://lists.oasis-open.org/archives/sca-c-cpp/200812/msg00011.html

 Comments   
Comment by Andrew Borley [ 11/Dec/08 10:08 AM ]
Opened in SCA C and C++ Telecon Thursday, 11th December 2008
See minutes at http://www.oasis-open.org/committees/event.php?event_id=19310
Comment by Bryan Aupperle [ 05/Mar/09 01:32 PM ]
Resolved in SCA C and C++ Telecon Thursday, 5th March 2009
See minutes at http://www.oasis-open.org/committees/event.php?event_id=19322
Comment by Bryan Aupperle [ 26/Mar/09 08:42 AM ]
Issue closed in Committee Draft 03. Approved in in SCA C and C++ Telecon Thursday, 19 March 2009.
See minutes at http://www.oasis-open.org/committees/event.php?event_id=19324




[CCPP-54] C++ Support for Long Running Request-Response Operations
Created: 10/Dec/08  Updated: 26/Mar/09

Status: Closed
Project: OASIS SCA C-CPP TC
Component/s: C++ specification
Affects Version/s: Version 1.1
Fix Version/s: Version 1.1

Type: Bug Priority: Major
Reporter: Andrew Borley Assigned To: Bryan Aupperle
Resolution: Fixed Votes: 0


 Description   
Target: C++ Client and Implementation Specification

Description: The Assembly TC has resolved http://www.osoa.org/jira/browse/ASSEMBLY-33 which points out that some services may implement request-response operations that may take a considerable time (think potentially days) to complete. The resolution is found in this document: .

We need to consider what, if any, support we which to add for this sort of operation.

On the implementation side, do we want to allow interfaces or functions to be marked as this type of service?

On the client side, do we want to provide either asynchronous or polling functions for these sorts of operations (we could force the binding to deal with the asynchronous nature of the response, but this could leave threads blocked for a long time).

Proposal:
TBD

Raised to the OASIS Service Component Architecture / C and C++ (SCA-C-C++) TC in the e-mail at http://lists.oasis-open.org/archives/sca-c-cpp/200812/msg00010.html

 Comments   
Comment by Andrew Borley [ 11/Dec/08 10:09 AM ]
Opened in SCA C and C++ Telecon Thursday, 11th December 2008
See minutes at http://www.oasis-open.org/committees/event.php?event_id=19310
Comment by Bryan Aupperle [ 05/Mar/09 01:32 PM ]
Resolved in SCA C and C++ Telecon Thursday, 5th March 2009
See minutes at http://www.oasis-open.org/committees/event.php?event_id=19322
Comment by Bryan Aupperle [ 26/Mar/09 08:41 AM ]
Issue closed in Committee Draft 03. Approved in in SCA C and C++ Telecon Thursday, 19 March 2009.
See minutes at http://www.oasis-open.org/committees/event.php?event_id=19324




[CCPP-53] Concurrency Model for each scope
Created: 02/Dec/08  Updated: 05/Mar/09

Status: Closed
Project: OASIS SCA C-CPP TC
Component/s: C specification, C++ specification
Affects Version/s: Version 1.1
Fix Version/s: Version 1.1

Type: Bug Priority: Major
Reporter: Andrew Borley Assigned To: Bryan Aupperle
Resolution: Fixed Votes: 0


 Description   
Target: SCA C++ and C C&I Specifications: sca-cppcni-1.1-spec-cd01-rev3.doc and sca-ccni-1.1-spec-cd01-rev3.doc (section 2.3 of each spec).

Description:
From (http://www.osoa.org/jira/browse/JAVA-61): The spec needs language to describe the concurrency model that a component developer needs to be prepared for when using any of the scopes. For example, the spec never describes whether or not a composite scoped implementation needs to be able to support concurrent execution on the same runtime instance.

The Java TC at a Nov. F2F adopted the following:

1) Stateless Scope
Single threaded - the SCA runtime MUST ensure that an implementation instance object is only ever dispatched on ONE thread at any one time. In addition, within the SCA lifecycle of an instance, the SCA runtime MUST only make a single invocation of one business method. (NB the SCA lifecycle might not correspond to the Java object lifecycle due to runtime techniques such as pooling)
2) Composite Scope
Multi-threaded - the SCA runtime MAY run multiple threads in a single implementation instance object and it MUST NOT perform any synchronization
3) Conversation scope
Multi-threaded - the SCA runtime MAY run multiple threads in a single implementation instance object and it MUST NOT perform any synchronization

Proposal:

Awaiting final wording from Java

Raised to the OASIS Service Component Architecture / C and C++ (SCA-C-C++) TC in the e-mail at http://lists.oasis-open.org/archives/sca-c-cpp/200812/msg00003.html

 Comments   
Comment by Andrew Borley [ 04/Dec/08 10:36 AM ]
Opened in SCA C and C++ Telecon Thursday, 4th December 2008
See minutes at http://www.oasis-open.org/committees/event.php?event_id=19309
Comment by Andrew Borley [ 08/Jan/09 10:12 AM ]
Resolved in SCA C and C++ Telecon Thursday, 8th January 2009
See minutes at http://www.oasis-open.org/committees/event.php?event_id=19314
Comment by Bryan Aupperle [ 05/Mar/09 01:21 PM ]
Issue closed in Committee Draft 02. Approved in in SCA C and C++ Telecon Thursday, 5 February 2009.
See minutes at http://www.oasis-open.org/committees/event.php?event_id=19318




[CCPP-52] Document conventions
Created: 02/Dec/08  Updated: 05/Mar/09

Status: Closed
Project: OASIS SCA C-CPP TC
Component/s: C specification, C++ specification
Affects Version/s: Version 1.1
Fix Version/s: Version 1.1

Type: Bug Priority: Major
Reporter: Andrew Borley Assigned To: Bryan Aupperle
Resolution: Fixed Votes: 0


 Description   
Target: SCA C++ and C C&I Specifications: sca-cppcni-1.1-spec-cd01-rev3.doc and sca-ccni-1.1-spec-cd01-rev3.doc

Description:

The SCA Liaison committee has asked us to add a small section on naming conventions to the
frontmatter of the SCA C++ and C C&I specifications.

This needs to cover conventions for the names that are defined by SCA in particular:

- names of elements and attributes in XSD files
- names of intents

This would be a good place to document typographic conventions as well:

- XML attributes are identified in text as @attribute
- Language identifiers used in text are in courier
- Literals in text are in italics

Proposal:

To each document, add a new section - 1.4:

1.4 Conventions

1.4.1 Naming Conventions
This specification follows some naming conventions for artifacts defined by the specification,
as follows:

    * For the names of elements and the names of attributes within XSD files, the names follow
      the CamelCase convention, with all names starting with a lower case letter.
      e.g. <element name="componentType" type="sca:ComponentType"/>
    * For the names of types within XSD files, the names follow the CamelCase convention with
      all names starting with an upper case letter
      e.g. <complexType name="ComponentService">
    * For the names of intents, the names follow the CamelCase convention, with all names
      starting with a lower case letter, EXCEPT for cases where the intent represents an
      established acronym, in which case the entire name is in upper case.
      An example of an intent which is an acronym is the "SOAP" intent.

1.4.2 Typographic Conventions
This specification follows some typographic conventions for some specific constructs

    * XML attributes are identified in text as @attribute
    * Language identifiers used in text are in courier
    * Literals in text are in italics

Raised to the OASIS Service Component Architecture / C and C++ (SCA-C-C++) TC in the e-mail at http://lists.oasis-open.org/archives/sca-c-cpp/200812/msg00002.html

 Comments   
Comment by Andrew Borley [ 04/Dec/08 10:35 AM ]
Opened in SCA C and C++ Telecon Thursday, 4th December 2008
See minutes at http://www.oasis-open.org/committees/event.php?event_id=19309
Comment by Andrew Borley [ 04/Dec/08 10:39 AM ]
Resolved in SCA C and C++ Telecon Thursday, 4th December 2008
See minutes at http://www.oasis-open.org/committees/event.php?event_id=19309
Comment by Bryan Aupperle [ 05/Mar/09 01:20 PM ]
Issue closed in Committee Draft 02. Approved in in SCA C and C++ Telecon Thursday, 5 February 2009.
See minutes at http://www.oasis-open.org/committees/event.php?event_id=19318




[CCPP-51] Correct C++ Terminology
Created: 06/Oct/08  Updated: 05/Mar/09

Status: Closed
Project: OASIS SCA C-CPP TC
Component/s: C++ specification
Affects Version/s: Version 1.1
Fix Version/s: Version 1.1

Type: Bug Priority: Major
Reporter: Bryan Aupperle Assigned To: Bryan Aupperle
Resolution: Fixed Votes: 0


 Description   
Target: C++ Client and Implementation Specification

Description: The current specification. has numerous occurrences of "method" which is not correct C++ terminology. Most of these are in prose and can be easily changed to either "member function" or "operation" based on context (i.e. specific to C++ or referring to a service operation). However, we also have method and callbackMethod child elements in interface.cpp and a method child element in implementation.cpp (the method child elements both appeared in the 1.0 schema).

Proposal:
1) Replace "method" in the prose with either "member function" or "operation" as appropriate for the context..
2) Rename the method child elements to function (memberFunction seems cumbersome here). This is a significant change and needs to be noted in the migration appendix. We should allow an implementation to support both method and function child elements.
3) Rename the callbackMethod child element to callbadkFunction. This child element was not in the 1.0 schema so this is a less significant change.

Raised to the OASIS Service Component Architecture / C and C++ (SCA-C-C++) TC in the e-mail at http://lists.oasis-open.org/archives/sca-c-cpp/200810/msg00002.html

 Comments   
Comment by Bryan Aupperle [ 28/Oct/08 12:41 PM ]
Opened in SCA C and C++ Telecon Thursday, 23 October 2008
See minutes at http://www.oasis-open.org/committees/event.php?event_id=19303
Comment by Andrew Borley [ 12/Nov/08 08:25 AM ]
Resolved in SCA C and C++ Telecon Thursday, 6th November 2008
See minutes at http://www.oasis-open.org/committees/event.php?event_id=19305
Comment by Bryan Aupperle [ 05/Mar/09 01:20 PM ]
Issue closed in Committee Draft 02. Approved in in SCA C and C++ Telecon Thursday, 5 February 2009.
See minutes at http://www.oasis-open.org/committees/event.php?event_id=19318




[CCPP-50] Support for assembly's @wiredByImpl
Created: 05/Sep/08  Updated: 05/Mar/09

Status: Deferred
Project: OASIS SCA C-CPP TC
Component/s: C specification, C++ specification
Affects Version/s: Version 1.1
Fix Version/s: Version 1.1

Type: Bug Priority: Major
Reporter: Andrew Borley Assigned To: Bryan Aupperle
Resolution: Unresolved Votes: 0


 Description   
Target: C & C++ C&I Specifications

Description: Add additional APIs to support Assembly's @wiredByImpl

The Assembly 1.0 specification defines the following attribute on a
reference element:

"wiredByImpl (optional) - a boolean value, "false" by default, which
indicates that the implementation wires this reference dynamically. If
set to "true" it indicates that the target of the reference is set at
runtime by the implementation code (eg by the code obtaining an endpoint
reference by some means and setting this as the target of the reference
through the use of programming interfaces defined by the relevant Client
and Implementation specification). If "true" is set, then the reference
should not be wired statically within a composite, but left unwired."

This implies that the C/C++ APIs should provide a mechanism for setting
the service that would be associated with a reference, however the
current ComponentContext API (in C++) only provides a "getService()"
method.

A simple "setService()" call may not be sufficient, as the state rules
may require multiple instances of the service to exist.

Proposal:

none

Raised to the OASIS Service Component Architecture / C and C++ (SCA-C-C++) TC in the e-mail at http://lists.oasis-open.org/archives/sca-c-cpp/200809/msg00004.html


 Comments   
Comment by Andrew Borley [ 15/Sep/08 06:03 AM ]
Opened in SCA C and C++ Telecon Thursday, 11 September 2008
See minutes at http://www.oasis-open.org/committees/event.php?event_id=16746
Comment by Bryan Aupperle [ 05/Mar/09 01:24 PM ]
Issue deferred in SCA C and C++ Telecon Thursday, 5 Mar2009.
See minutes at http://www.oasis-open.org/committees/event.php?event_id=19322




[CCPP-49] Use #pragms for C/C++ Annotations.
Created: 25/Aug/08  Updated: 05/Mar/09

Status: Closed
Project: OASIS SCA C-CPP TC
Component/s: C specification, C++ specification
Affects Version/s: Version 1.1
Fix Version/s: Version 1.1

Type: Bug Priority: Major
Reporter: David Haney Assigned To: Bryan Aupperle
Resolution: No Action Votes: 0


 Description   
Target: C & C++ C&I Specifications

Description: Use #pragma for C/C++ Annotations

The current specification uses annotations embedded in comments in order to provide additional information about methods and arguments. The
C/C++ languages also provide a #pragma preprocessor directive that allows specifying additional information to a compiler about the code.
Instead of using comments for SCA annotations, we could instead use #pragmas.

Pros:
- Follows convention of other C/C++ extensions (like OpenMP).
- Allows rudimentary namespacing of directives

Cons:
- Some compilers will ignore when unrecognized pragmas are present.
        Users will need to disable those warnings. (They are required by
        The standard to not fail on unrecognized pragams).

Proposal:

The simplest implementation would involve replacing the existing convention of:

// @WebService(name="op1")

With something like:

#pragma sca WebService(name="op1")

We could also investigate changing the format, I'm not sure if that would be necessary or what that should look like.

Raised to the OASIS Service Component Architecture / C and C++ (SCA-C-C++) TC in the e-mail at http://lists.oasis-open.org/archives/sca-c-cpp/200808/msg00028.html

 Comments   
Comment by Bryan Aupperle [ 05/Mar/09 01:26 PM ]
Issue closed-no action in SCA C and C++ Telecon Thursday, 5 Mar2009.
See minutes at http://www.oasis-open.org/committees/event.php?event_id=19322




[CCPP-48] Policy Intent cleanup
Created: 19/Aug/08  Updated: 05/Mar/09

Status: Closed
Project: OASIS SCA C-CPP TC
Component/s: C specification, C++ specification
Affects Version/s: Version 1.1
Fix Version/s: Version 1.1

Type: Bug Priority: Major
Reporter: Bryan Aupperle Assigned To: Bryan Aupperle
Resolution: Fixed Votes: 0


 Description   
Target: C & C++ C&I specifications CD-01 Rev 1 Section B.9 (of each)

Description:

This section describes the annotations for the security policy intents defined in the Policy Framework along with examples of their use and meaning.

Since this section was adapted from the Java CAA specification, the Policy TC has defined intents for transactions and reliable messaging.

We need to identify the annotations for these intents and also decide what if any explanatory text should be removed for being redundant with the Policy Framework.

Proposal:

None at present.

Raised to the OASIS Service Component Architecture / C and C++ (SCA-C-C++) TC in the e-mail at http://lists.oasis-open.org/archives/sca-c-cpp/200808/msg00017.html

 Comments   
Comment by Andrew Borley [ 27/Oct/08 10:59 AM ]
Resolved in SCA C and C++ Telecon Thursday, 23rd October 2008
See minutes at http://www.oasis-open.org/committees/event.php?event_id=19303
Comment by Bryan Aupperle [ 05/Mar/09 01:20 PM ]
Issue closed in Committee Draft 02. Approved in in SCA C and C++ Telecon Thursday, 5 February 2009.
See minutes at http://www.oasis-open.org/committees/event.php?event_id=19318




[CCPP-47] C Conformance Text
Created: 19/Aug/08  Updated: 05/Mar/09

Status: Closed
Project: OASIS SCA C-CPP TC
Component/s: C specification
Affects Version/s: Version 1.1
Fix Version/s: Version 1.1

Type: Bug Priority: Major
Reporter: Bryan Aupperle Assigned To: Bryan Aupperle
Resolution: Fixed Votes: 0


 Description   
Target: C C&I specification CD-01 Rev 1

Description:

Formal, conformance points need to be defined and section 13 needs to be written.

The conformance points are the specific, testable, behaviors an implementation follows.

Proposal:

None at present.

Raised to the OASIS Service Component Architecture / C and C++ (SCA-C-C++) TC in the e-mail at http://lists.oasis-open.org/archives/sca-c-cpp/200808/msg00015.html

 Comments   
Comment by Andrew Borley [ 20/Nov/08 10:54 AM ]
Resolved in SCA C and C++ Telecon Thursday, 20th November 2008
See minutes at http://www.oasis-open.org/committees/event.php?event_id=19307
Comment by Bryan Aupperle [ 05/Mar/09 01:20 PM ]
Issue closed in Committee Draft 02. Approved in in SCA C and C++ Telecon Thursday, 5 February 2009.
See minutes at http://www.oasis-open.org/committees/event.php?event_id=19318




[CCPP-46] C++ Conformance Text
Created: 19/Aug/08  Updated: 05/Mar/09

Status: Closed
Project: OASIS SCA C-CPP TC
Component/s: C++ specification
Affects Version/s: Version 1.1
Fix Version/s: Version 1.1

Type: Bug Priority: Major
Reporter: Bryan Aupperle Assigned To: Bryan Aupperle
Resolution: Fixed Votes: 0


 Description   
Target: C++ C&I specification CD-01 Rev 1

Description:

Formal, conformance points need to be defined and section 13 needs to be written.

The conformance points are the specific, testable, behaviors an implementation follows.

Proposal:

None at present.

Raised to the OASIS Service Component Architecture / C and C++ (SCA-C-C++) TC in the e-mail at http://lists.oasis-open.org/archives/sca-c-cpp/200808/msg00016.html

 Comments   
Comment by Andrew Borley [ 14/Nov/08 05:28 AM ]
Resolved in SCA C and C++ Telecon Thursday, 13th November 2008
See minutes at http://www.oasis-open.org/apps/org/workgroup/sca-c-cpp/event.php?event_id=19306
Comment by Bryan Aupperle [ 05/Mar/09 01:19 PM ]
Issue closed in Committee Draft 02. Approved in in SCA C and C++ Telecon Thursday, 5 February 2009.
See minutes at http://www.oasis-open.org/committees/event.php?event_id=19318




[CCPP-45] C API detail
Created: 19/Aug/08  Updated: 05/Mar/09

Status: Closed
Project: OASIS SCA C-CPP TC
Component/s: C specification
Affects Version/s: Version 1.1
Fix Version/s: Version 1.1

Type: Bug Priority: Major
Reporter: Bryan Aupperle Assigned To: Bryan Aupperle
Resolution: Fixed Votes: 0


 Description   
Target: C C&I specification CD-01 Rev 1

Description:

Section 7 of the C specification describes the SCA APIs.

These APIs have several functions with various parameters and return values. The descriptions of these functions are all very brief and do not adequately describe preconditions, postconditions, nor adequately describe the parameter values and return values for the functions.

The lack of clarity and detail means that implementers and users of the API cannot be sure what is expected from each function.

Proposal:

None at present.

Raised to the OASIS Service Component Architecture / C and C++ (SCA-C-C++) TC in the e-mail at http://lists.oasis-open.org/archives/sca-c-cpp/200808/msg00013.html

 Comments   
Comment by Bryan Aupperle [ 05/Mar/09 01:19 PM ]
Issue closed in Committee Draft 02. Approved in in SCA C and C++ Telecon Thursday, 5 February 2009.
See minutes at http://www.oasis-open.org/committees/event.php?event_id=19318




[CCPP-44] C++ API detail
Created: 19/Aug/08  Updated: 05/Mar/09

Status: Closed
Project: OASIS SCA C-CPP TC
Component/s: C++ specification
Affects Version/s: Version 1.1
Fix Version/s: Version 1.1

Type: Bug Priority: Major
Reporter: Bryan Aupperle Assigned To: Bryan Aupperle
Resolution: Fixed Votes: 0


 Description   
Target: C++ C&I specification CD-01 Rev 1

Description:

Section 7.2 and 7.3 of the C++ specification describes the Component Context and Service Reference APIs.

These APIs have several methods with various parameters and return values. The descriptions of these methods are all very brief and do not adequately describe preconditions, postconditions, nor adequately describe the parameter values and return values for the methods.

The lack of clarity and detail means that implementers and users of the API cannot be sure what is expected from each method.

Proposal:

None at present.

Raised to the OASIS Service Component Architecture / C and C++ (SCA-C-C++) TC in the e-mail at http://lists.oasis-open.org/archives/sca-c-cpp/200808/msg00014.htm

 Comments   
Comment by Andrew Borley [ 12/Nov/08 08:26 AM ]
Resolved in SCA C and C++ Telecon Thursday, 6th November 2008
See minutes at http://www.oasis-open.org/committees/event.php?event_id=19305
Comment by Bryan Aupperle [ 05/Mar/09 01:19 PM ]
Issue closed in Committee Draft 02. Approved in in SCA C and C++ Telecon Thursday, 5 February 2009.
See minutes at http://www.oasis-open.org/committees/event.php?event_id=19318




[CCPP-43] Preserving State of C components
Created: 19/Aug/08  Updated: 05/Mar/09

Status: Deferred
Project: OASIS SCA C-CPP TC
Component/s: C specification
Affects Version/s: Version 1.1
Fix Version/s: Version 1.1

Type: Bug Priority: Major
Reporter: Bryan Aupperle Assigned To: Bryan Aupperle
Resolution: Unresolved Votes: 0


 Description   
TARGET: C++ C&I Spec

DESCRIPTION: Section 2.3.4 of the C spec discusses the possibility of passivating a service implementation instance in a long-running conversation, however it doesn't define how implementation state should be preserved.

PROPOSAL: This is a initial view of a possible set of APIs to provide this functionality.
A component that needs to have state maintained requests the space it needs from the SCA runtime SCAStateAlloc() and can access the persistent state with SCAGetState(). SCAStateAlloc() returns a block of memory that will associated with the requesting component instance for the rest of the instance's lifecycle. The component uses this memory for all relevant state data. If a component instance might be passivated, it is considered best practice to call SCAGetState() to endure a valid pointer before accessing any persistent data. If a component is implemented as a program, SCAGetState() can be called on any invocation of an operation of a service of the component as needed.
void SCAStateAlloc(int bytesNeeded,
                   void **stateBuffer
                   int *compCode,
                   int *reason);

void SCAGetState(void **stateBuffer
                 int *compCode,
                 int *reason);

Raised to the OASIS Service Component Architecture / C and C++ (SCA-C-C++) TC in the e-mail at http://lists.oasis-open.org/archives/sca-c-cpp/200808/msg00012.html

 Comments   
Comment by Andrew Borley [ 29/Jan/09 10:35 AM ]
Opened in SCA C and C++ Telecon Thursday, 21st August 2008
See minutes at http://www.oasis-open.org/committees/event.php?event_id=16743
Comment by Bryan Aupperle [ 05/Mar/09 01:24 PM ]
Issue deferred in SCA C and C++ Telecon Thursday, 5 Mar2009.
See minutes at http://www.oasis-open.org/committees/event.php?event_id=19322




[CCPP-42] C/WSDL Mapping
Created: 19/Aug/08  Updated: 05/Mar/09

Status: Closed
Project: OASIS SCA C-CPP TC
Component/s: C specification
Affects Version/s: Version 1.1
Fix Version/s: Version 1.1

Type: Bug Priority: Major
Reporter: Bryan Aupperle Assigned To: Bryan Aupperle
Resolution: Fixed Votes: 0


 Description   
Target: C Client and Implementation Specification

Description: The current C/WSDL mapping on a combination of the OMG WSDL to C++ mapping and the C++ to WSDL mapping defined in the OSOA C++ C&I specification. We have concluded that this combination does not work for C++ and we need to make corresponding changes to the C C&I spec.

Proposal: Base revised mappings on the resolution of issue 17.

Raised to the OASIS Service Component Architecture / C and C++ (SCA-C-C++) TC in the e-mail at http://lists.oasis-open.org/archives/sca-c-cpp/200808/msg00011.html

 Comments   
Comment by Andrew Borley [ 29/Jan/09 10:33 AM ]

Opened in SCA C and C++ Telecon Thursday, 21st August 2008
See minutes at http://www.oasis-open.org/committees/event.php?event_id=16743
Comment by Andrew Borley [ 29/Jan/09 10:34 AM ]
Resolved in SCA C and C++ Telecon Thursday, 29th January 2009
See minutes at http://www.oasis-open.org/committees/event.php?event_id=19317
Comment by Bryan Aupperle [ 05/Mar/09 01:19 PM ]
Issue closed in Committee Draft 02. Approved in in SCA C and C++ Telecon Thursday, 5 February 2009.
See minutes at http://www.oasis-open.org/committees/event.php?event_id=19318




[CCPP-41] Rework C++ Packaging
Created: 23/May/08  Updated: 05/Mar/09

Status: Closed
Project: OASIS SCA C-CPP TC
Component/s: C++ specification
Affects Version/s: Version 1.1
Fix Version/s: Version 1.1

Type: Bug Priority: Major
Reporter: Andrew Borley Assigned To: Bryan Aupperle
Resolution: Fixed Votes: 0


 Description   
RAISER: Bryan Aupperle

TARGET: SCA C++ Specification section titled "Packaging" (9 of CD 01)

DESCRIPTION: The packaging sections of our specifications are a bit out of date with the current Assembly specification. The Assembly specification defines contributions which contain deployable composites as well as imports (artifacts referenced that are outside of the contribution) and exports (parts of a composite that can be referenced by other composites). Imports and exports are defined as extension points. There is no mention of contributions in the packaging sections of our specifications, nor is there any discussion of using imports to point to executables that may be outside of a contribution.
The current content was done late in the 1.0 time frame and just a snapshot of the then current Tuscany work and does not reflect the current Assembly specification
Use cases exist for both export and import
A more up to date example would be appropriate.

PROPOSAL: None at this time

 Comments   
Comment by Andrew Borley [ 05/Jun/08 10:52 AM ]
Opened in SCA C and C++ Telecon Thursday, 5 June 2008
See minutes at http://www.oasis-open.org/committees/event.php?event_id=16732
Comment by Andrew Borley [ 18/Jul/08 06:26 AM ]
Resolved in SCA C and C++ Telecon Thursday, 17th July 2008
See minutes at http://www.oasis-open.org/committees/event.php?event_id=16738
Comment by Bryan Aupperle [ 05/Mar/09 01:19 PM ]
Issue closed in Committee Draft 02. Approved in in SCA C and C++ Telecon Thursday, 5 February 2009.
See minutes at http://www.oasis-open.org/committees/event.php?event_id=19318




[CCPP-40] Rework C Packaging
Created: 23/May/08  Updated: 05/Mar/09

Status: Closed
Project: OASIS SCA C-CPP TC
Component/s: C specification
Affects Version/s: Version 1.1
Fix Version/s: Version 1.1

Type: Bug Priority: Major
Reporter: Andrew Borley Assigned To: Bryan Aupperle
Resolution: Fixed Votes: 0


 Description   
RAISER: Bryan Aupperle

TARGET: SCA C Specification section titled "Packaging" (10 of CD 01)

DESCRIPTION: The packaging sections of our specifications are a bit out of date with the current Assembly specification. The Assembly specification defines contributions which contain deployable composites as well as imports (artifacts referenced that are outside of the contribution) and exports (parts of a composite that can be referenced by other composites). Imports and exports are defined as extension points. There is no mention of contributions in the packaging sections of our specifications, nor is there any discussion of using imports to point to executables that may be outside of a contribution.
The current content was done late in the 1.0 time frame and is based on the then current Tuscany work and does not reflect the current Assembly specification
Use cases exist for both export and import
A more up to date example would be appropriate.

PROPOSAL: None at this time

 Comments   
Comment by Andrew Borley [ 05/Jun/08 10:51 AM ]
Opened in SCA C and C++ Telecon Thursday, 5 June 2008
See minutes at http://www.oasis-open.org/committees/event.php?event_id=16732
Comment by Andrew Borley [ 31/Jul/08 10:34 AM ]
Resolved in SCA C and C++ Telcon Thursday, 31st July 2008
See minutes at http://www.oasis-open.org/committees/event.php?event_id=16740
Comment by Bryan Aupperle [ 05/Mar/09 01:18 PM ]
Issue closed in Committee Draft 02. Approved in in SCA C and C++ Telecon Thursday, 5 February 2009.
See minutes at http://www.oasis-open.org/committees/event.php?event_id=19318




[CCPP-39] Support of Scopes
Created: 30/Apr/08  Updated: 22/Jan/09

Status: Closed
Project: OASIS SCA C-CPP TC
Component/s: C specification, C++ specification
Affects Version/s: Version 1.1
Fix Version/s: Version 1.1

Type: Bug Priority: Major
Reporter: Andrew Borley Assigned To: Bryan Aupperle
Resolution: No Action Votes: 0


 Description   
TARGET: SCA C++ and C Specification sections titled "Component Implementation Scopes" (2.3 of CD 01)

DESCRIPTION: The Java Common Annotation and API specification states that support for scopes is optional while the C++ and C C&I specifications requires support for the stateless, conversation, request and composite scopes.

Specifically from the Java CAA spec:

This document defines four scopes:
STATELESS
REQUEST
CONVERSATION
COMPOSITE
Java-based implementation types can choose to support any of these scopes, and they MAY also define new scopes specific to their type.
...
The following sections specify four standard scopes which a Java-based implementation type MAY support.

But from the C++ C&I (and the wording in the C C&I spec is equivalent) :
The SCA C++ Client and Implementation Model mandates support for the four basic scopes; stateless, request, conversation, and composite. Additional scopes MAY be provided by SCA runtimes.
...
The following sections specify the scopes an SCA runtime MUST support for C++ component implementations.

PROPOSAL: Change the support of scopes from required to optional. I.e. the above becomes:
The SCA C++ Client and Implementation Model allows support for the four basic scopes; stateless, request, conversation, and composite. Additional scopes MAY be provided by SCA runtimes.
...
The following sections specify the scopes an SCA runtime MAYsupport for C++ component implementations.

 Comments   
Comment by Andrew Borley [ 02/May/08 04:28 AM ]
Opened in SCA C and C++ Telecon Thursday, 1 May 2008
See minutes at http://www.oasis-open.org/committees/event.php?event_id=16727
Comment by Andrew Borley [ 22/Jan/09 10:12 AM ]
Closed as no-action due to CCPP-56 in SCA C and C++ Telecon Thursday, 22nd January 2009
See minutes at http://www.oasis-open.org/apps/group_public/event.php?event_id=19316




[CCPP-38] Further clarification to the relationship of conversational interfaces and scope conversation
Created: 10/Mar/08  Updated: 22/Jan/09

Status: Closed
Project: OASIS SCA C-CPP TC
Component/s: C specification, C++ specification
Affects Version/s: Version 1.1
Fix Version/s: Version 1.1

Type: Bug Priority: Major
Reporter: Andrew Borley Assigned To: Bryan Aupperle
Resolution: No Action Votes: 0


 Description   
Target: C++ and C specifications

Description: The Java TC has approved some further clarifications to the relationship of Conversational interfaces and conversational scope.

Specifically, in addition to the prior restriction that conversation scoped components must only provide conversational interfaces, the new restriction is that conversational interfaces can only be provided by conversation scoped components.

Proposal:
Adopt the additional restriction.

Raised to the OASIS Service Component Architecture / C and C++ (SCA-C-C++) TC in the e-mail at http://lists.oasis-open.org/archives/sca-c-cpp/200803/msg00005.html

 Comments   
Comment by Andrew Borley [ 17/Mar/08 02:32 PM ]
Opened in SCA C and C++ Telecon Thursday, 13 March 2008
See minutes at http://www.oasis-open.org/committees/event.php?event_id=16720
Comment by Andrew Borley [ 22/Jan/09 10:11 AM ]
Closed as no-action due to CCPP-56 in SCA C and C++ Telecon Thursday, 22nd January 2009
See minutes at http://www.oasis-open.org/apps/group_public/event.php?event_id=19316




[CCPP-37] Clarify Request Scope lifetime
Created: 10/Mar/08  Updated: 05/Mar/09

Status: Closed
Project: OASIS SCA C-CPP TC
Component/s: C specification, C++ specification
Affects Version/s: Version 1.1
Fix Version/s: Version 1.1

Type: Bug Priority: Major
Reporter: Andrew Borley Assigned To: Bryan Aupperle
Resolution: Fixed Votes: 0


 Description   
TARGET: SCA C++ and C Specification sections titled "Request Scope" (2.3.2 of WD 04)

DESCRIPTION:

The section currently contains the following sentence:

"The lifecycle of request scope extends from the point a request on a remotable interface enters the SCA runtime and a thread processes that request until the thread completes synchronously processing the request."

From this description, it is not clear whether the request scope lasts through a remotable call to another component that happens to be local. In one possible interpretation it would depend on the binding. A call through a web service binding would be seen as changing threads, and therefore would be a new request scope. The same call through an SCA binding might be assumed to remain within the thread and therefore be within the same scope.

It is probably a bad idea for the scope to depend on the binding that is used, and it may even be a bad idea for the scope to depend on whether a call through a remotable interface _happens_ to be local.

PROPOSALS:

None yet - wait on Assembly TC action.

Raised to the OASIS Service Component Architecture / C and C++ (SCA-C-C++) TC in the e-mail at http://lists.oasis-open.org/archives/sca-c-cpp/200803/msg00004.html

 Comments   
Comment by Andrew Borley [ 17/Mar/08 02:32 PM ]
Opened in SCA C and C++ Telecon Thursday, 13 March 2008
See minutes at http://www.oasis-open.org/committees/event.php?event_id=16720
Comment by Andrew Borley [ 14/Nov/08 05:27 AM ]
Resolved in SCA C and C++ Telecon Thursday, 13th November 2008
See minutes at http://www.oasis-open.org/apps/org/workgroup/sca-c-cpp/event.php?event_id=19306
Comment by Bryan Aupperle [ 05/Mar/09 01:18 PM ]
Issue closed in Committee Draft 02. Approved in in SCA C and C++ Telecon Thursday, 5 February 2009.
See minutes at http://www.oasis-open.org/committees/event.php?event_id=19318




[CCPP-36] Accessing SCA Services from non-SCA code
Created: 10/Mar/08  Updated: 26/Mar/09

Status: Closed
Project: OASIS SCA C-CPP TC
Component/s: C specification, C++ specification
Affects Version/s: Version 1.1
Fix Version/s: Version 1.1

Type: Bug Priority: Major
Reporter: Andrew Borley Assigned To: Bryan Aupperle
Resolution: Fixed Votes: 0


 Description   
TARGET: C++ and C specification,

        Section titled "Accessing Services from non-SCA component implementations" (3.2 of WD 04)

DESCRIPTION:

Code that is completely external to an SCA domain can communicate to SCA services through the externally advertised service bindings.

 

However, there is sometimes code that is deployed that shares much in common with the SCA domain. In increasing levels of coupling, the code might:

1. Have SCA APIs implemented to work with the target domain

2. The client code was deployed as part of an SCA deployment, but the code is not within an SCA component.

In either or both of these cases, we should provide a simple way for the client to access the target component.

The current specification implies that the client would accomplish this by retrieving a ComponentContext or SCAREF, although it does not describe what component to use for this purpose (after all, the client is not associated with a component).

PROPOSAL:

Nothing yet.

Raised to the OASIS Service Component Architecture / C and C++ (SCA-C-C++) TC in the e-mail at http://lists.oasis-open.org/archives/sca-c-cpp/200803/msg00003.html

 Comments   
Comment by Andrew Borley [ 17/Mar/08 02:31 PM ]
Opened in SCA C and C++ Telecon Thursday, 13 March 2008
See minutes at http://www.oasis-open.org/committees/event.php?event_id=16720
Comment by Bryan Aupperle [ 05/Mar/09 01:32 PM ]
Resolved in SCA C and C++ Telecon Thursday, 5th March 2009
See minutes at http://www.oasis-open.org/committees/event.php?event_id=19322
Comment by Bryan Aupperle [ 26/Mar/09 08:41 AM ]
Issue closed in Committee Draft 03. Approved in in SCA C and C++ Telecon Thursday, 19 March 2009.
See minutes at http://www.oasis-open.org/committees/event.php?event_id=19324




[CCPP-35] Replace ##any with ##other
Created: 13/Feb/08  Updated: 25/Mar/08

Status: Closed
Project: OASIS SCA C-CPP TC
Component/s: C specification, C++ specification
Affects Version/s: Version 1.1
Fix Version/s: Version 1.1

Type: Bug Priority: Major
Reporter: Andrew Borley Assigned To: Bryan Aupperle
Resolution: Fixed Votes: 0


 Description   
Target: C++ and C specifications

Description: The Assembly TC has replaced all occurrences of ##any in the schema with ##other. This prevents the use any elements from the sca namespace in extensions.

Proposal:
Replace the occurrences of ##any with ##other in the C++ and C schema.

Raised to the OASIS Service Component Architecture / C and C++ (SCA-C-C++) TC in the e-mail at http://lists.oasis-open.org/archives/sca-c-cpp/200802/msg00005.html

 Comments   
Comment by Andrew Borley [ 20/Feb/08 11:06 AM ]
Opened in SCA C and C++ Telecon Thursday, 14th February 2007
See minutes at http://www.oasis-open.org/committees/event.php?event_id=16716
Comment by Andrew Borley [ 20/Feb/08 11:09 AM ]
Resolved in SCA C and C++ Telecon Thursday, 14th February 2007
See minutes at http://www.oasis-open.org/committees/event.php?event_id=16716
Comment by Andrew Borley [ 25/Mar/08 07:19 AM ]
Issue closed in Committee Draft 01. Approved in in SCA C and C++ Telecon Thursday, 20 March 2008
See minutes at http://www.oasis-open.org/committees/event.php?event_id=16721




[CCPP-34] Clarify relationship of conversational interfaces and scope
Created: 13/Feb/08  Updated: 25/Mar/08

Status: Closed
Project: OASIS SCA C-CPP TC
Component/s: C specification, C++ specification
Affects Version/s: Version 1.1
Fix Version/s: Version 1.1

Type: Bug Priority: Major
Reporter: Andrew Borley Assigned To: Bryan Aupperle
Resolution: Fixed Votes: 0


 Description   
Target: C++ and C specifications

Description: The Java TC has approved some clarifications to the relationship of Conversational interfaces and conversational scope. Specifically they added these words to the equivalent of section 2.3.4 of our specifications:
A conversational scoped class MUST NOT expose a service using a non-conversational interface.
and these words to the section on conversational services (equivalent of 5.2 for C++ and 4.2 for C)
A class which provides a service with a conversational interface can have any scope. In particular, it is not necessary for the class to have conversation scope. If the class has conversation scope, the class benefits from the runtime maintaining state associated with the conversation, typically through routing each operation invocation associated with the conversation to the same instance of the class, with state data held in instance variables within the class. However, for classes of any scope, when an operation of a conversational interface is executing, the ComponentContext.getConversationID() returns the conversation ID of the conversation. The conversation ID can be used by the class as an index to store and to look up state data associated with the conversation, using some suitable storage mechanism.

Proposal:
Add these same clarifications to our specifications with the obvious and appropriate modifications to the C++ and C specifications.

Raised to the OASIS Service Component Architecture / C and C++ (SCA-C-C++) TC in the e-mail at http://lists.oasis-open.org/archives/sca-c-cpp/200802/msg00004.html

 Comments   
Comment by Andrew Borley [ 20/Feb/08 11:06 AM ]
Opened in SCA C and C++ Telecon Thursday, 14th February 2007
See minutes at http://www.oasis-open.org/committees/event.php?event_id=16716
Comment by Andrew Borley [ 20/Feb/08 11:08 AM ]
Resolved in SCA C and C++ Telecon Thursday, 14th February 2007
See minutes at http://www.oasis-open.org/committees/event.php?event_id=16716
Comment by Andrew Borley [ 25/Mar/08 07:19 AM ]
Issue closed in Committee Draft 01. Approved in in SCA C and C++ Telecon Thursday, 20 March 2008
See minutes at http://www.oasis-open.org/committees/event.php?event_id=16721




[CCPP-33] Should dependency injection be used in the C++ and C specifications
Created: 13/Feb/08  Updated: 05/Mar/09

Status: Closed
Project: OASIS SCA C-CPP TC
Component/s: C specification, C++ specification
Affects Version/s: Version 1.1
Fix Version/s: Version 1.1

Type: Bug Priority: Major
Reporter: Andrew Borley Assigned To: Bryan Aupperle
Resolution: Fixed Votes: 0


 Description   
Target: C++ and C specifications

Description:
In information discussion the TC has indicated that it doesn't feel that
dependency injection is necessary at this point in the specification,
however dependency injection is implied in section 12 (requirements
around default constructors, and getters/setters with particular APIs.).


Proposal:
We need to decide at what level dependency injection will be supported
by the C and C++ specifications, and review the specification to make
sure usage is in line with that decision.

Raised to the OASIS Service Component Architecture / C and C++ (SCA-C-C++) TC in the e-mail at http://lists.oasis-open.org/archives/sca-c-cpp/200802/msg00003.html


 Comments   
Comment by Andrew Borley [ 20/Feb/08 11:05 AM ]
Opened in SCA C and C++ Telecon Thursday, 14th February 2007
See minutes at http://www.oasis-open.org/committees/event.php?event_id=16716
Comment by Bryan Aupperle [ 05/Mar/09 01:29 PM ]
Issue resolved by changes for resolution of issues 17 and 43 in SCA C and C++ Telecon Thursday, 5 Mar 2009.
See minutes at http://www.oasis-open.org/committees/event.php?event_id=19322
Comment by Bryan Aupperle [ 05/Mar/09 01:30 PM ]
Issue is closed since issues 17 and 42 are already closed.




[CCPP-32] Remove callback customization
Created: 28/Jan/08  Updated: 25/Mar/08

Status: Closed
Project: OASIS SCA C-CPP TC
Component/s: C specification, C++ specification
Affects Version/s: Version 1.1
Fix Version/s: Version 1.1

Type: Bug Priority: Major
Reporter: Andrew Borley Assigned To: Bryan Aupperle
Resolution: Fixed Votes: 0


 Description   
Target: C++ and C specifications

Description: The Assembly TC has approved an resolution removing the callback customization functionality. This means the corresponding support needs to be removed from C++ and C.

Proposal:
Remove the setCallback() method from serviceReference and the corresponding discussion in section 6.2.4. Add a comment on this in the migration appendix.
Remove the SCASetCallback() function from the Asynchronous Programming API and the corresponding discussion in section 5.2.4. Add a comment on this in the migration appendix.

 Comments   
Comment by Andrew Borley [ 05/Feb/08 04:26 AM ]
Opened in SCA C and C++ Telecon Thursday, 31st January 2008
See minutes at http://www.oasis-open.org/committees/event.php?event_id=16714
Comment by Andrew Borley [ 05/Feb/08 04:27 AM ]
Resolved in SCA C and C++ Telecon Thursday, 31st January 2008
See minutes at http://www.oasis-open.org/committees/event.php?event_id=16714
Comment by Andrew Borley [ 25/Mar/08 07:19 AM ]
Issue closed in Committee Draft 01. Approved in in SCA C and C++ Telecon Thursday, 20 March 2008
See minutes at http://www.oasis-open.org/committees/event.php?event_id=16721




[CCPP-31] Should the C++ SCA spec define annotations
Created: 14/Dec/07  Updated: 25/Mar/08

Status: Closed
Project: OASIS SCA C-CPP TC
Component/s: C++ specification
Affects Version/s: Version 1.1
Fix Version/s: Version 1.1

Type: Bug Priority: Major
Reporter: Andrew Borley Assigned To: Bryan Aupperle
Resolution: Fixed Votes: 0


 Description   
TARGET: C++ C&I Specification

DESCRIPTION:
Should the C++ spec define annotations for marking up source code with
SCA service information? C++ does not natively define an annotation
format or behavior, so annotations must be defined as a language
extension that is both compatible with standard C++, and presumably that
would be parseable by an SCA defined parser. If the spec should define
an annotation system for C++, we also need to define conformance
guidelines for how those annotations will be used. (i.e., does the
runtime need to parse the C++ in order to extract that information? Are
annotations purely a design-time tool that allows code generation of
SCDL files? should annotations result in code that is compiled into the
library, that the runtime could query in order to extract a description
of the service).

PROPOSAL:
There seem to be three primary approaches that we could take towards
annotations, each with their associated implications.

1) Annotations are not defined by the spec.

The SCA runtime would rely solely on the SCDL files in order to describe
a service, and would not make any attempts to parse the source files at
runtime. This will require that some information to be duplicated
between the source code and the SCDL files that describe the source.

The SCA spec would not attempt to define a mechanism for generating SCDL
files from the source. It would leave it up to individual vendors to
define their own mechanism, which could be through the use of
annotations, or could be through some other proprietary mechanism.
Portability would be maintained at runtime in that each runtime would be
expected to consume SCDL files to retrieve description information, and
should be independent of whether the SCDL was written by hand or
generated from the source.

This has the benefit of removing the need to define an annotation system
in C++. Individual vendors would be free to define (or not define)
they're own schemes for creating SCDL for C++ code. Those schemes could
be annotation based, or could be provided by some other mechanism.


2) Annotations are a design-time tool to allow for generating SCDL
files.

As in (1), the SCA runtime would still rely solely on SCDL files in
order to describe the service; however the specification would also
define a mechanism for marking up code so that the SCDL files could be
generated from the source.

This is relatively close to what the current system supports, however it
would clarify the role of annotations in the SCA runtime, and precedence
rules for when information is defined in both the SCDL and in
annotations (the canonical information would need to be in SCDL,
annotations would not affect runtime behavior).

This has the same benefit as (1) in regard to defining where canonical
information is stored at runtime, in the SCDL files.

If this was the approach we decided to pursue, would annotation support
be required of a conforming implementation, or would this be a case
where annotations are still optional, however if annotations are
defined, they must follow this convention?

Since this isn't an issue for the runtime (it will still reference
SCDL), who would the conformance statements apply to? Is there a
conformance target for tools vendors (which could be independent of the
runtime vendors?).


3) Annotations are a runtime tool, allowing for programmatic
introspection (and possibly design-time introspection as well).

This is probably the most complex solution; however it would also
provide functionality that's closest to what's being provided by Java's
annotations. Under this mechanism, we would define an annotation system
in C++ that would allow us to introspect the class at runtime in order
to derive information.

On a cursory review, there are two forms this could take. One would be
to implement annotations through a macro-based system that would allow
us to insert methods that would provide meta-data about a service into
the service itself. Since C++ does not provide basic introspection for
classes (such as what methods a class provides), we would have to go
beyond the basic annotations that Java supports, and also define
mechanisms for defining methods and their arguments through the
annotations system as well. This could quickly result in us needing to
define both the method and a macro with meta-information about the
method for each method in the class. This seems like its going well
beyond what the language would normally support, and is probably on the
level of supporting dependency-injection, which we've implied is beyond
the scope of what we want to tackle in the spec at this point.

A second approach would be to generate a wrapper class around the user's
class that would provide the meta-information. The runtime could then
query this code-generated class at runtime in order to extract
information. This would require annotations similar to what's required
in (2). I'm not sure this would provide any benefit over parsing the
SCDL file to retrieve this information (as in 2), and would mandate more
about the runtime implementation than in (2).

There may be further options for how we could achieve (3) that would
eliminate some of the drawbacks outlined here.

 
On a first pass, (2) seems like it may be the safest choice. This would
maintain most of the compatibility with what was defined in OSOA 1.0,
however it would also clarify the role of annotations, which should make
writing conformance guidelines cleaner (and easier for vendors to
implement). (1) however is also very tempting, as it would greatly
simplify the spec (eliminating all discussion of annotations), and would
provide vendors more flexibility in how they want to generated SCDL from
source. Assuming we make supporting annotations optional, I believe (1)
becomes a degenerate case of (2), as a complying vendor could opt out of
supporting annotations, and could still provide an alternative mechanism
for generating SCDL.

A fourth option might be to go with (1) for the main specification,
however to also provide a supplementary specification that defines
conformance for a tool vendor to generate SCDL from source code. This
could even be a non-normative document that just provides a recommended
annotation format.
 
Raised to the OASIS Service Component Architecture / C and C++ (SCA-C-C++) TC in the e-mail at http://lists.oasis-open.org/archives/sca-c-cpp/200712/msg00016.html

 Comments   
Comment by Andrew Borley [ 07/Jan/08 08:00 AM ]
Opened in SCA C and C++ Telecon Thursday, 3rd January 2008
See minutes at http://www.oasis-open.org/committees/event.php?event_id=16710
Comment by Andrew Borley [ 13/Jan/08 03:47 PM ]
Resolved in SCA C and C++ Telecon Thursday, 10th January 2008
See minutes at http://www.oasis-open.org/apps/group_public/event.php?event_id=16711
Comment by Andrew Borley [ 25/Mar/08 07:19 AM ]
Issue closed in Committee Draft 01. Approved in in SCA C and C++ Telecon Thursday, 20 March 2008
See minutes at http://www.oasis-open.org/committees/event.php?event_id=16721




[CCPP-30] Conformance statements for optional SCDL attributes (Section 2.5)
Created: 12/Dec/07  Updated: 05/Mar/09

Status: Closed
Project: OASIS SCA C-CPP TC
Component/s: C++ specification
Affects Version/s: Version 1.1
Fix Version/s: Version 1.1

Type: Bug Priority: Major
Reporter: Andrew Borley Assigned To: Bryan Aupperle
Resolution: Fixed Votes: 0


 Description   
TARGET: C++ C&I Specification

DESCRIPTION:
The class and callbackClass attributes on interface.cpp and the class
attribute on implementation.cpp all indicate when the attribute is
optional, however they do not phrase when the attribute is required as a
conformance statement. The descriptions should be updated to clarify
when the attribute is required.

PROPOSAL:
Working under the assumption that each of these attributes are required
if the header contains more than one class, the following text is
proposed:

interface.cpp:
* class - optional name of the class declaration in the header file,
including any namespace definition. If the header contains more than
one class, then this attribute MUST be specified.
* callbackClass - optional name of the class declaration for the
callback in the callback header file, including any namespace
definition. If the header contains more than one class, then this
attribute MUST be specified.

implementation.cpp:
* class - optional name of the class declaration of the implementation,
including any namespace definition. If the header contains more than
one class, then this attribute MUST be specified.

If these attributes are not required when multiple classes are listed,
then this issue may be invalid.

Raised to the OASIS Service Component Architecture / C and C++ (SCA-C-C++) TC in the e-mail at http://lists.oasis-open.org/archives/sca-c-cpp/200712/msg00010.html

 Comments   
Comment by Andrew Borley [ 14/Dec/07 03:15 AM ]
Opened in SCA C and C++ Telecon Thursday, 13th December 2007
See minutes at http://www.oasis-open.org/committees/event.php?event_id=16707
Comment by Andrew Borley [ 14/Nov/08 05:28 AM ]
Resolved in SCA C and C++ Telecon Thursday, 13th November 2008
See minutes at http://www.oasis-open.org/apps/org/workgroup/sca-c-cpp/event.php?event_id=19306
Comment by Bryan Aupperle [ 05/Mar/09 01:17 PM ]
Issue closed in Committee Draft 02. Approved in in SCA C and C++ Telecon Thursday, 5 February 2009.
See minutes at http://www.oasis-open.org/committees/event.php?event_id=19318




[CCPP-29] WSDL 2.0 and C
Created: 11/Dec/07  Updated: 05/Mar/09

Status: Closed
Project: OASIS SCA C-CPP TC
Component/s: C specification
Affects Version/s: Version 1.1
Fix Version/s: Version 1.1

Type: Bug Priority: Major
Reporter: Andrew Borley Assigned To: Bryan Aupperle
Resolution: Fixed Votes: 0


 Description   
Target: C C&I spec.

Description: Much of the WSDL related language is 1.1 specific and needs to be modified to include WSDL 2.0

Proposal: None at this time.

Raised to the OASIS Service Component Architecture / C and C++ (SCA-C-C++) TC in the e-mail at http://lists.oasis-open.org/archives/sca-c-cpp/200712/msg00006.html

 Comments   
Comment by Andrew Borley [ 14/Dec/07 03:16 AM ]
Opened in SCA C and C++ Telecon Thursday, 13th December 2007
See minutes at http://www.oasis-open.org/committees/event.php?event_id=16707
Comment by Andrew Borley [ 27/Oct/08 11:00 AM ]
Resolved in SCA C and C++ Telecon Thursday, 23rd October 2008
See minutes at http://www.oasis-open.org/committees/event.php?event_id=19303
Comment by Bryan Aupperle [ 05/Mar/09 01:17 PM ]
Issue closed in Committee Draft 02. Approved in in SCA C and C++ Telecon Thursday, 5 February 2009.
See minutes at http://www.oasis-open.org/committees/event.php?event_id=19318




[CCPP-28] WSDL 2.0 and C++
Created: 11/Dec/07  Updated: 05/Mar/09

Status: Closed
Project: OASIS SCA C-CPP TC
Component/s: C++ specification
Affects Version/s: Version 1.1
Fix Version/s: Version 1.1

Type: Bug Priority: Major
Reporter: Andrew Borley Assigned To: Bryan Aupperle
Resolution: Fixed Votes: 0


 Description   
Target: C++ C&I spec.

Description: Much of the WSDL related language is 1.1 specific and needs to be modified to include WSDL 2.0

Proposal: None at this time.

Raised to the OASIS Service Component Architecture / C and C++ (SCA-C-C++) TC in the e-mail at http://lists.oasis-open.org/archives/sca-c-cpp/200712/msg00005.html

 Comments   
Comment by Andrew Borley [ 14/Dec/07 03:16 AM ]
Opened in SCA C and C++ Telecon Thursday, 13th December 2007
See minutes at http://www.oasis-open.org/committees/event.php?event_id=16707
Comment by Andrew Borley [ 27/Oct/08 10:59 AM ]
Resolved in SCA C and C++ Telecon Thursday, 23rd October 2008
See minutes at http://www.oasis-open.org/committees/event.php?event_id=19303
Comment by Bryan Aupperle [ 05/Mar/09 01:17 PM ]
Issue closed in Committee Draft 02. Approved in in SCA C and C++ Telecon Thursday, 5 February 2009.
See minutes at http://www.oasis-open.org/committees/event.php?event_id=19318




[CCPP-27] C componentType file name and location
Created: 11/Dec/07  Updated: 25/Mar/08

Status: Closed
Project: OASIS SCA C-CPP TC
Component/s: C specification
Affects Version/s: Version 1.1
Fix Version/s: Version 1.1

Type: Bug Priority: Major
Reporter: Andrew Borley Assigned To: Bryan Aupperle
Resolution: Fixed Votes: 0


 Description   
TARGET: C C&I Specification

Description: We need to finalize the name and location of componentType files as well as any other SCDL metadata related to componentType files.

Key points from the assembly specification:
- Lines 482-483 of WD01 state that the componentType file has the same name as the implementation file but the extension .componentType. But the location is implementation technology dependent (lines 484-486).
- In the SCDL, the component only defines the componentType indirectly via the implementation.xxx
- The componentType schema does not provide a name for a componentType

As I see the requirements:
- The information in implementation.xxx must uniquely identify the componentType file.
- It needs to be possible to find the file in a simple manner.
- It is reasonable to expect multiple component implementations to be compiled into a single DLL/shared library/etc.

Proposal:
The current draft has a problem in that there is no public implementation artifact that uniquely identifies an implementation (the source file is probably not considered public). We need to add a specific componentType attribute to implementation.c. The value of this attribute would be the componentType name, including an optional path.

Raised to the OASIS Service Component Architecture / C and C++ (SCA-C-C++) TC in the e-mail at http://lists.oasis-open.org/archives/sca-c-cpp/200712/msg00004.html

 Comments   
Comment by Andrew Borley [ 14/Dec/07 03:16 AM ]
Opened in SCA C and C++ Telecon Thursday, 13th December 2007
See minutes at http://www.oasis-open.org/committees/event.php?event_id=16707
Comment by Andrew Borley [ 21/Jan/08 06:15 AM ]
Resolved in SCA C and C++ Telecon Thursday, 17th January 2008
See minutes at http://www.oasis-open.org/apps/group_public/event.php?event_id=16712
Comment by Andrew Borley [ 25/Mar/08 07:19 AM ]
Issue closed in Committee Draft 01. Approved in in SCA C and C++ Telecon Thursday, 20 March 2008
See minutes at http://www.oasis-open.org/committees/event.php?event_id=16721




[CCPP-26] C++ componentType file name and location
Created: 11/Dec/07  Updated: 25/Mar/08

Status: Closed
Project: OASIS SCA C-CPP TC
Component/s: C++ specification
Affects Version/s: Version 1.1
Fix Version/s: Version 1.1

Type: Bug Priority: Major
Reporter: Andrew Borley Assigned To: Bryan Aupperle
Resolution: Fixed Votes: 0


 Description   
TARGET: C++ C&I Specification

Description: We need to finalize the name and location of componentType files as well as any other SCDL metadata related to componentType files.

Key points from the assembly specification:
- Lines 482-483 of WD01 state that the componentType file has the same name as the implementation file but the extension .componentType. But the location is implementation technology dependent (lines 484-486).
- In the SCDL, the component only defines the componentType indirectly via the implementation.xxx
- The componentType schema does not provide a name for a componentType

As I see the requirements:
- The information in implementation.xxx must uniquely identify the componentType file.
- It needs to be possible to find the file in a simple manner.
- It is reasonable to expect multiple component implementations to be compiled into a single DLL/shared library/etc.

Proposal:
Naming: There are two choices.
1) The implementation name is considered to be the implementation header name. This implies an implementation header MUST only contain one class defining a componentType (it MAY contain other classes).
2) The implementation name is considered to be the implementation class name. This means if the implementation class is the only class in the header file then the header file must be parsed to find the class name. Alternatively we could make the implementation class attribute required.

I favor option 1 as the least metadata to specify and being consistent with common programming practice.

Location: The current text requires a header file that declares the implementation class and that this file be available from the SCA registry/repository - specifically using a relative path from the composite root. The logical place for the componentType file to be placed is in the same directory as the implementation header file. The only reason I can think of to do something different is if we believe there is a requirement to place implementation header files in a directory with restricted access and componentType files in a publically readable directory. I do not believe this is a requirement.

Raised to the OASIS Service Component Architecture / C and C++ (SCA-C-C++) TC in the e-mail at http://lists.oasis-open.org/archives/sca-c-cpp/200712/msg00003.html

 Comments   
Comment by Andrew Borley [ 14/Dec/07 03:15 AM ]
Opened in SCA C and C++ Telecon Thursday, 13th December 2007
See minutes at http://www.oasis-open.org/committees/event.php?event_id=16707
Comment by Andrew Borley [ 13/Jan/08 03:44 PM ]
Resolved in SCA C and C++ Telecon Thursday, 10 January 2008
See minutes at http://www.oasis-open.org/apps/group_public/event.php?event_id=16711
Comment by Andrew Borley [ 25/Mar/08 07:19 AM ]
Issue closed in Committee Draft 01. Approved in in SCA C and C++ Telecon Thursday, 20 March 2008
See minutes at http://www.oasis-open.org/committees/event.php?event_id=16721




[CCPP-25] Preserving state in passivated Conversational scopes
Created: 30/Nov/07  Updated: 05/Mar/09

Status: Deferred
Project: OASIS SCA C-CPP TC
Component/s: C++ specification
Affects Version/s: Version 1.1
Fix Version/s: Version 1.1

Type: Bug Priority: Major
Reporter: Andrew Borley Assigned To: Bryan Aupperle
Resolution: Unresolved Votes: 0


 Description   
TARGET: C++ C&I Spec

DESCRIPTION: Section 2.3.4 of the C++ spec discusses the possibility of
passivating a service implementation instance in a long-running
conversation, however it doesn't define how implementation state should
be preserved.

PROPOSAL:

The following is an initial take at replacing/clarifying the last
sentence of the first paragraph of section 2.3.4:

"If this occurs, the runtime MUST provide a mechanism for preserving
instance state information. An SCA runtime MUST NOT passivate an
implementation instance if it cannot preserve implementation state."

Does that help to clarify the expected behavior? This still leaves us
with the responsibility for writing conformance tests for this scenario,
which may be difficult.

An alternative might be to wash our hands of passivating implementation
instances (replacing the last two sentences).

"This specification does not define a mechanism for passivating
long-running conversational implementation instances. An implementation
MAY provide a mechanism for passivating implementation instances."

A third option might be to define in the C++ API a mechanism to allow
users to preserve state. One approach would be to provide a simple API
that a service implementor could derive from and implement in order to
provide persistence/restoration capabilities on their implementations.

class PersistableService {
  virtual ~PersistableService();

  /**
   * Returns a string containing the serialized state associated
   * with this service.
   */
  virtual std::string persistState(void) = 0;

  /**
   * Reads the state information for this service from the
   * serialized state information in \a state.
   */
  virtual void restoreState(const std::string& state) = 0;
};

Alternatively we could add additional annotations to allow the user to
identify their own persist/restore methods (we'd still probably need to
specify the return type/parameters of the methods).

This would restrict how a runtime could support passivating a service
(by requiring this mechanism), but it will also ensure that there's a
portable mechanism for persisting user state across runtime
implementations.


Raised to the OASIS Service Component Architecture / C and C++ (SCA-C-C++) TC in the e-mail at http://lists.oasis-open.org/archives/sca-c-cpp/200711/msg00025.html

 Comments   
Comment by Andrew Borley [ 07/Dec/07 03:24 AM ]
Opened in SCA C and C++ Telecon Thursday, 06th December 2007
See minutes at http://www.oasis-open.org/committees/event.php?event_id=16706
Comment by Bryan Aupperle [ 05/Mar/09 01:24 PM ]
Issue deferred in SCA C and C++ Telecon Thursday, 5 Mar2009.
See minutes at http://www.oasis-open.org/committees/event.php?event_id=19322




[CCPP-24] Define Conformance Targets
Created: 11/Nov/07  Updated: 17/Jan/08

Status: Closed
Project: OASIS SCA C-CPP TC
Component/s: C specification, C++ specification
Affects Version/s: Version 1.1
Fix Version/s: Version 1.1

Type: Bug Priority: Major
Reporter: Andrew Borley Assigned To: Bryan Aupperle
Resolution: No Action Votes: 0


 Description   
TARGET: C and C++ C&I Specs

DESCRIPTION: In order to write a normative statement or conformance clause using RFC2119 language, the target or subject of the rule needs to be included. Some of these are obvious, as we have rules governing components, composites, services, references etc. Other targets are less so, especially when it comes to conformance, as we need to identify artefacts that vendors can claim they handle according to the rules of the spec. We should enumerate a list of conformance targets early on, so that every time we use a MUST, MAY, or SHOULD, we know to what the rule applies to.

PROPOSAL: none

Raised to the OASIS Service Component Architecture / C and C++ (SCA-C-C++) TC in the e-mail at http://lists.oasis-open.org/archives/sca-c-cpp/200711/msg00013.html

 Comments   
Comment by Andrew Borley [ 16/Nov/07 03:17 AM ]
Opened in SCA C and C++ Telecon Thursday, 15th November 2007
See minutes at http://www.oasis-open.org/committees/event.php?event_id=16703
Comment by Andrew Borley [ 13/Jan/08 03:45 PM ]
Resolved in SCA C and C++ Telecon Thursday, 10 January 2008
See minutes at http://www.oasis-open.org/apps/group_public/event.php?event_id=16711




[CCPP-23] Define a grammar for C++ annotations
Created: 24/Oct/07  Updated: 05/Mar/09

Status: Closed
Project: OASIS SCA C-CPP TC
Component/s: C++ specification
Affects Version/s: Version 1.1
Fix Version/s: Version 1.1

Type: Bug Priority: Major
Reporter: Andrew Borley Assigned To: Bryan Aupperle
Resolution: Fixed Votes: 0


 Description   
Target: C++ Client and Implementation Model / C++ Annotations

Description:
The current description of C++ annotations is currently informal, with
the main definition of what they look like coming through examples.
Since C++ does not natively define a concept of annotations (like Java),
we should provide an explicit grammar for interpreting annotation
syntax. This includes defining both the explicit syntax, as well as any
relationship between references in the annotation to the rest of the
source. For example, in the proposal for supporting intent annotations,
one of the annotations references a #define string.

Proposal:
<none>

Raised to the OASIS Service Component Architecture / C and C++ (SCA-C-C++) TC in the e-mail at http://lists.oasis-open.org/archives/sca-c-cpp/200710/msg00070.html

 Comments   
Comment by Andrew Borley [ 26/Oct/07 08:39 AM ]
Opened in SCA C and C++ Telecon Thursday, 25 October 2007
See minutes at http://www.oasis-open.org/committees/event.php?event_id=16700
Comment by Andrew Borley [ 10/Mar/08 08:59 AM ]
Resolved in SCA C and C++ Telecon Thursday, 28th February 2007
See minutes at http://www.oasis-open.org/committees/event.php?event_id=16718
Comment by Bryan Aupperle [ 05/Mar/09 01:16 PM ]
Issue closed in Committee Draft 02. Approved in in SCA C and C++ Telecon Thursday, 5 February 2009.
See minutes at http://www.oasis-open.org/committees/event.php?event_id=19318




[CCPP-22] Define a grammar for C Annotations
Created: 24/Oct/07  Updated: 05/Mar/09

Status: Closed
Project: OASIS SCA C-CPP TC
Component/s: C specification
Affects Version/s: Version 1.1
Fix Version/s: Version 1.1

Type: Bug Priority: Major
Reporter: Andrew Borley Assigned To: Bryan Aupperle
Resolution: Fixed Votes: 0


 Description   
Target: C Client and Implementation Model / C Annotations

Description:
The current description of C annotations is currently informal, with the
main definition of what they look like coming through examples. Since C
does not natively define a concept of annotations (like Java), we should
provide an explicit grammar for interpreting annotation syntax. This
includes defining both the explicit syntax, as well as any relationship
between references in the annotation to the rest of the source. For
example, in the proposal for supporting intent annotations, one of the
annotations references a #define string.

Proposal:
<none>

Raised to the OASIS Service Component Architecture / C and C++ (SCA-C-C++) TC in the e-mail at http://lists.oasis-open.org/archives/sca-c-cpp/200710/msg00069.html

 Comments   
Comment by Andrew Borley [ 26/Oct/07 08:39 AM ]
Opened in SCA C and C++ Telecon Thursday, 25 October 2007
See minutes at http://www.oasis-open.org/committees/event.php?event_id=16700
Comment by Andrew Borley [ 17/Mar/08 02:29 PM ]
Resolved in SCA C and C++ Telecon Thursday, 13th March 2007
See minutes at http://www.oasis-open.org/committees/event.php?event_id=16720
Comment by Bryan Aupperle [ 05/Mar/09 01:16 PM ]
Issue closed in Committee Draft 02. Approved in in SCA C and C++ Telecon Thursday, 5 February 2009.
See minutes at http://www.oasis-open.org/committees/event.php?event_id=19318




[CCPP-21] Appendix describing migration from OSOA 1.0 spec for C++
Created: 24/Oct/07  Updated: 25/Mar/08

Status: Closed
Project: OASIS SCA C-CPP TC
Component/s: C++ specification
Affects Version/s: Version 1.1
Fix Version/s: Version 1.1

Type: Bug Priority: Major
Reporter: Andrew Borley Assigned To: Bryan Aupperle
Resolution: Fixed Votes: 0


 Description   
Target: C++ Client and Implementation Model

Description:
The charter for the SCA-C-CPP TC requires the inclusion of a migration
guide for porting applications written against the OSOA specification to
OASIS specification.

Proposal:
Add an appendix "Migration from the OSOA SCA C++ Client and
Implementation Model 1.0 (non-normative)" to the C++ Client and
Implementation Model specification to maintain any migration issues. As
changes are introduced to the C++ Client and Implementation Model
specification, notes should be added to this section describing the
change necessary to move from a 1.0 compliant model to a version
compatible with this version of the spec, as well as any implementor
notes or recommendations for how backward compatibility may be
maintained.

Raised to the OASIS Service Component Architecture / C and C++ (SCA-C-C++) TC in the e-mail at http://lists.oasis-open.org/archives/sca-c-cpp/200710/msg00068.html

 Comments   
Comment by Andrew Borley [ 26/Oct/07 08:39 AM ]
Opened in SCA C and C++ Telecon Thursday, 25 October 2007
See minutes at http://www.oasis-open.org/committees/event.php?event_id=16700
Comment by Andrew Borley [ 21/Jan/08 06:14 AM ]
Resolved in SCA C and C++ Telecon Thursday, 17th January 2008
See minutes at http://www.oasis-open.org/apps/group_public/event.php?event_id=16712
Comment by Andrew Borley [ 25/Mar/08 07:19 AM ]
Issue closed in Committee Draft 01. Approved in in SCA C and C++ Telecon Thursday, 20 March 2008
See minutes at http://www.oasis-open.org/committees/event.php?event_id=16721




[CCPP-20] Appendix describing migration from OSOA 1.0 spec for C
Created: 24/Oct/07  Updated: 25/Mar/08

Status: Closed
Project: OASIS SCA C-CPP TC
Component/s: C specification
Affects Version/s: Version 1.1
Fix Version/s: Version 1.1

Type: Bug Priority: Major
Reporter: Andrew Borley Assigned To: Bryan Aupperle
Resolution: Fixed Votes: 0


 Description   
Target: C Client and Implementation Model

Description:
The charter for the SCA-C-CPP TC requires the inclusion of a migration
guide for porting applications written against the OSOA specification to
OASIS specification.

Proposal:
Add an appendix "Migration from the OSOA SCA C Client and Implementation
Model 1.0 (non-normative)" to the C Client and Implementation Model
specification to maintain any migration issues. As changes are
introduced to the C Client and Implementation Model specification, notes
should be added to this section describing the change necessary to move
from a 1.0 compliant model to a version compatible with this version of
the spec, as well as any implementor notes or recommendations for how
backward compatibility may be maintained.

Raised to the OASIS Service Component Architecture / C and C++ (SCA-C-C++) TC in the e-mail at http://lists.oasis-open.org/archives/sca-c-cpp/200710/msg00067.html

 Comments   
Comment by Andrew Borley [ 26/Oct/07 08:39 AM ]
Opened in SCA C and C++ Telecon Thursday, 25 October 2007
See minutes at http://www.oasis-open.org/committees/event.php?event_id=16700
Comment by Andrew Borley [ 28/Jan/08 07:13 AM ]
Resolved in SCA C and C++ Telecon Thursday, 24th January 2008
See minutes at http://www.oasis-open.org/apps/group_public/event.php?event_id=16713
Comment by Andrew Borley [ 25/Mar/08 07:19 AM ]
Issue closed in Committee Draft 01. Approved in in SCA C and C++ Telecon Thursday, 20 March 2008
See minutes at http://www.oasis-open.org/committees/event.php?event_id=16721




[CCPP-19] Define rules for applying annotations to C++ language elements
Created: 19/Oct/07  Updated: 25/Mar/08

Status: Closed
Project: OASIS SCA C-CPP TC
Component/s: C++ specification
Affects Version/s: Version 1.1
Fix Version/s: Version 1.1

Type: Bug Priority: Major
Reporter: Andrew Borley Assigned To: Bryan Aupperle
Resolution: Fixed Votes: 0


 Description   
Target: C++ Client and Implementation Model/C++ Annotations

Description: The specification does not formally define how annotations are applied to language elements (class vs. method etc.). With the introduction of @Requires and @PolicySets that can be applied to multiple types of elements, this detail is needed.

Proposal: Forthcoming.

Raised to the OASIS Service Component Architecture / C and C++ (SCA-C-C++) TC in the e-mail at http://lists.oasis-open.org/archives/sca-c-cpp/200710/msg00057.html

 Comments   
Comment by Andrew Borley [ 26/Oct/07 08:39 AM ]
Opened in SCA C and C++ Telecon Thursday, 25 October 2007
See minutes at http://www.oasis-open.org/committees/event.php?event_id=16700
Comment by Andrew Borley [ 26/Oct/07 08:46 AM ]
Resolved in SCA C and C++ Telecon Thursday, 25 October 2007
See minutes at http://www.oasis-open.org/committees/event.php?event_id=16700
Comment by Andrew Borley [ 25/Mar/08 07:19 AM ]
Issue closed in Committee Draft 01. Approved in in SCA C and C++ Telecon Thursday, 20 March 2008
See minutes at http://www.oasis-open.org/committees/event.php?event_id=16721




[CCPP-18] Define rules for applying annotations to C language elements
Created: 19/Oct/07  Updated: 25/Mar/08

Status: Closed
Project: OASIS SCA C-CPP TC
Component/s: C specification
Affects Version/s: Version 1.1
Fix Version/s: Version 1.1

Type: Bug Priority: Major
Reporter: Andrew Borley Assigned To: Bryan Aupperle
Resolution: Fixed Votes: 0


 Description   
Target: C Client and Implementation Model/C Annotations

Description: The specification does not formally define how annotations are applied to language elements (set of function vs. specific function etc.). With the introduction of @Requires and @PolicySets that can be applied to multiple types of elements, this detail is needed.

Proposal: Forthcoming.

Raised to the OASIS Service Component Architecture / C and C++ (SCA-C-C++) TC in the e-mail at http://lists.oasis-open.org/archives/sca-c-cpp/200710/msg00058.html

 Comments   
Comment by Andrew Borley [ 26/Oct/07 08:40 AM ]
Opened in SCA C and C++ Telecon Thursday, 25 October 2007
See minutes at http://www.oasis-open.org/committees/event.php?event_id=16700
Comment by Andrew Borley [ 01/Nov/07 11:25 AM ]
Resolved in SCA C and C++ Telecon Thursday, 01 November 2007
See minutes at http://www.oasis-open.org/committees/event.php?event_id=16701
Comment by Andrew Borley [ 25/Mar/08 07:19 AM ]
Issue closed in Committee Draft 01. Approved in in SCA C and C++ Telecon Thursday, 20 March 2008
See minutes at http://www.oasis-open.org/committees/event.php?event_id=16721




[CCPP-17] Should C++ -> WSDL Roundtrip with WSDL -> C++
Created: 11/Oct/07  Updated: 05/Mar/09

Status: Closed
Project: OASIS SCA C-CPP TC
Component/s: C++ specification
Affects Version/s: Version 1.1
Fix Version/s: Version 1.1

Type: Bug Priority: Major
Reporter: Andrew Borley Assigned To: Bryan Aupperle
Resolution: Fixed Votes: 0


 Description   
Target:: C++ Client and Implementation Model
 
Description:
The current C++ C&I defines the conversion from WSDL to C++ according to the OMG specification, however it defines its own convention for converting from C++ to WSDL. These conversion rules do not appear to be compatible, causing a WSDL -> C++ -> WSDL conversion to result in a different WSDL than the original input, or potentially to even produce C++ code that cannot be converted back into WSDL according the current rules. The C&I should either clarify that these conversions are not possible, or the conversions should be made compatible.
 
Proposal(s):
1) Modify the current C++ -> WSDL specification to be compatible with the OMG specification
2) Abandon the OMG specification, and make the WSDL -> C++ mapping consistent with the current specification.

Raised to the OASIS Service Component Architecture / C and C++ (SCA-C-C++) TC in the e-mail at http://lists.oasis-open.org/archives/sca-c-cpp/200710/msg00040.html

 Comments   
Comment by Andrew Borley [ 12/Oct/07 07:11 AM ]
Opened in SCA C and C++ Telecon Thursday, 11 October 2007
See minutes at http://www.oasis-open.org/apps/group_public/event.php?event_id=16698
Comment by Andrew Borley [ 29/Jan/09 10:15 AM ]
Resolved in SCA C and C++ Telecon Thursday, 29th January 2009
See minutes at http://www.oasis-open.org/committees/event.php?event_id=19317
Comment by Bryan Aupperle [ 05/Mar/09 01:16 PM ]
Issue closed in Committee Draft 02. Approved in in SCA C and C++ Telecon Thursday, 5 February 2009.
See minutes at http://www.oasis-open.org/committees/event.php?event_id=19318




[CCPP-16] Make C conversational annotations consistent with Java
Created: 10/Oct/07  Updated: 25/Mar/08

Status: Closed
Project: OASIS SCA C-CPP TC
Component/s: C specification
Affects Version/s: Version 1.1
Fix Version/s: Version 1.1

Type: Bug Priority: Major
Reporter: Andrew Borley Assigned To: Bryan Aupperle
Resolution: Fixed Votes: 0


 Description   
Target: C Client and Implementation Model/C Annotations

Description: Currently the conversational annotations for C are (@Conversation and @EndConversation) are inconsistent with those of Java (@Conversational, @ConversationAttributes, and @EndsConversation). We should make them consistent. While it is unlikely that a programmer will be working in both languages, this change would also ensure consistency in the corresponding SCDL

Proposal: Change @EndConversation to @EndsConversation, change @Conversation to @ConversationAttributes and add @Conversational (which is an interface annotation).

Raised to the OASIS Service Component Architecture / C and C++ (SCA-C-C++) TC in the e-mail at http://lists.oasis-open.org/archives/sca-c-cpp/200710/msg00033.html

 Comments   
Comment by Andrew Borley [ 12/Oct/07 07:10 AM ]
Opened in SCA C and C++ Telecon Thursday, 11 October 2007
See minutes at http://www.oasis-open.org/apps/group_public/event.php?event_id=16698
Comment by Andrew Borley [ 26/Oct/07 08:46 AM ]
Resolved in SCA C and C++ Telecon Thursday, 25 October 2007
See minutes at http://www.oasis-open.org/committees/event.php?event_id=16700
Comment by Andrew Borley [ 25/Mar/08 07:19 AM ]
Issue closed in Committee Draft 01. Approved in in SCA C and C++ Telecon Thursday, 20 March 2008
See minutes at http://www.oasis-open.org/committees/event.php?event_id=16721




[CCPP-15] Make C++ conversational annotations consistent with Java
Created: 10/Oct/07  Updated: 25/Mar/08

Status: Closed
Project: OASIS SCA C-CPP TC
Component/s: C++ specification
Affects Version/s: Version 1.1
Fix Version/s: Version 1.1

Type: Bug Priority: Major
Reporter: Andrew Borley Assigned To: Bryan Aupperle
Resolution: Fixed Votes: 0


 Description   
Target: C++ Client and Implementation Model/C++ Annotations

Description: Currently the conversational annotations for C++ are (@Conversation and @EndConversation) are inconsistent with those of Java (@Conversational, @ConversationAttributes, and @EndsConversation). We should make them consistent. While it is unlikely that a programmer will be working in both languages, this change would also ensure consistency in the corresponding SCDL

Proposal: Change @EndConversation to @EndsConversation, change @Conversation to @ConversationAttributes and add @Conversational (which is an interface annotation).

Raised to the OASIS Service Component Architecture / C and C++ (SCA-C-C++) TC in the e-mail at http://lists.oasis-open.org/archives/sca-c-cpp/200710/msg00032.html

 Comments   
Comment by Andrew Borley [ 12/Oct/07 07:10 AM ]
Opened in SCA C and C++ Telecon Thursday, 11 October 2007
See minutes at http://www.oasis-open.org/apps/group_public/event.php?event_id=16698
Comment by Andrew Borley [ 19/Oct/07 09:12 AM ]
Resolved in SCA C and C++ Telecon Thursday, 19 October 2007
See minutes at http://www.oasis-open.org/committees/event.php?event_id=16699
Comment by Andrew Borley [ 25/Mar/08 07:19 AM ]
Issue closed in Committee Draft 01. Approved in in SCA C and C++ Telecon Thursday, 20 March 2008
See minutes at http://www.oasis-open.org/committees/event.php?event_id=16721




[CCPP-14] Incorrect targetNamespace for schema types in Section 6.4 (Class mapping).
Created: 05/Oct/07  Updated: 25/Mar/08

Status: Closed
Project: OASIS SCA C-CPP TC
Component/s: C++ specification
Affects Version/s: Version 1.1
Fix Version/s: Version 1.1

Type: Bug Priority: Major
Reporter: Andrew Borley Assigned To: Bryan Aupperle
Resolution: Fixed Votes: 0


 Description   
Target: C++ Client and Implementation Model

Description: This is an item noted from the 1.0 spec found at http://www.oasis-open.org/committees/download.php/25351/SCA_ClientAndImplementationModel_Cpp-V100-1.pdf

The targetNamespace for the schema types was inconsistent with the namespace prefix used when referencing the types in the WSDL. The targetNamespace for schema types should match the namespace associated with the tns prefix.

line 2145: http://sample/MyService should be changed to http://MyService

Proposal: Fix the namespace as suggested

Raised to the OASIS Service Component Architecture / C and C++ (SCA-C-C++) TC in the e-mail at http://lists.oasis-open.org/archives/sca-c-cpp/200710/msg00028.html

 Comments   
Comment by Andrew Borley [ 12/Oct/07 07:09 AM ]
Opened in SCA C and C++ Telecon Thursday, 11 October 2007
See minutes at http://www.oasis-open.org/apps/group_public/event.php?event_id=16698
Comment by Andrew Borley [ 12/Oct/07 07:10 AM ]
Resolved in SCA C and C++ Telecon Thursday, 11 October 2007
See minutes at http://www.oasis-open.org/apps/group_public/event.php?event_id=16698
Comment by Andrew Borley [ 25/Mar/08 07:19 AM ]
Issue closed in Committee Draft 01. Approved in in SCA C and C++ Telecon Thursday, 20 March 2008
See minutes at http://www.oasis-open.org/committees/event.php?event_id=16721




[CCPP-13] Incorrect variable name in Section 6.4 (Class mapping).
Created: 05/Oct/07  Updated: 25/Mar/08

Status: Closed
Project: OASIS SCA C-CPP TC
Component/s: C++ specification
Affects Version/s: Version 1.1
Fix Version/s: Version 1.1

Type: Bug Priority: Major
Reporter: Andrew Borley Assigned To: Bryan Aupperle
Resolution: Fixed Votes: 0


 Description   
Target: C++ Client and Implementation Model

Description: This is an item noted from the 1.0 spec found at http://www.oasis-open.org/committees/download.php/25351/SCA_ClientAndImplementationModel_Cpp-V100-1.pdf

The generated name for the response variable is incorrect.

line 2172: myMethodResponseData should be changed to myOtherMethodResponseData.

Proposal: Update the generated name as suggested

Raised to the OASIS Service Component Architecture / C and C++ (SCA-C-C++) TC in the e-mail at http://lists.oasis-open.org/archives/sca-c-cpp/200710/msg00027.html

 Comments   
Comment by Andrew Borley [ 12/Oct/07 07:09 AM ]
Opened in SCA C and C++ Telecon Thursday, 11 October 2007
See minutes at http://www.oasis-open.org/apps/group_public/event.php?event_id=16698
Comment by Andrew Borley [ 12/Oct/07 07:09 AM ]
Resolved in SCA C and C++ Telecon Thursday, 11 October 2007
See minutes at http://www.oasis-open.org/apps/group_public/event.php?event_id=16698
Comment by Andrew Borley [ 25/Mar/08 07:19 AM ]
Issue closed in Committee Draft 01. Approved in in SCA C and C++ Telecon Thursday, 20 March 2008
See minutes at http://www.oasis-open.org/committees/event.php?event_id=16721




[CCPP-12] Incorrect C++ to WSDL type mappings in Appendix 5.
Created: 05/Oct/07  Updated: 25/Mar/08

Status: Closed
Project: OASIS SCA C-CPP TC
Component/s: C++ specification
Affects Version/s: Version 1.1
Fix Version/s: Version 1.1

Type: Bug Priority: Major
Reporter: Andrew Borley Assigned To: Bryan Aupperle
Resolution: Fixed Votes: 0


 Description   
Target: C++ Client and Implementation Model

Description: This is an item noted from the 1.0 spec found at http://www.oasis-open.org/committees/download.php/25351/SCA_ClientAndImplementationModel_Cpp-V100-1.pdf

Some of the examples in Appendix 5 (C++ to WSDL Mapping) map C++ types to incorrect WSDL types, based on the mapping table in section 6.2.1. The following lines should be updated to reflect the correct mapping.

line 1730: id (C++ type: int) should map to an xsd:short.
line 1760: idList (C++ type: int) should map to an xsd:short.
line 1785: multiIdArray (C++ type: int) should map to an xsd:short.
line 1813: id (C++ type: int) should map to an xsd:short.
line 1841: id (C++ type: int) should map to an xsd:short.
line 1871: id (C++ type: int) should map to an xsd:short.
line 2158: myMethodResponseData (C++ return type: int) should map to an xsd:short.
line 2256: id (C++ type: int) should map to an xsd:short.
line 2272: id (C++ type: int) should map to an xsd:short.
line 2372: id (c++ type: int) should map to an xsd:short.

Proposal: Update the mapping as suggested

Raised to the OASIS Service Component Architecture / C and C++ (SCA-C-C++) TC in the e-mail at http://lists.oasis-open.org/archives/sca-c-cpp/200710/msg00026.html

 Comments   
Comment by Andrew Borley [ 12/Oct/07 07:07 AM ]
Opened in SCA C and C++ Telecon Thursday, 11 October 2007
See minutes at http://www.oasis-open.org/apps/group_public/event.php?event_id=16698
Comment by Andrew Borley [ 12/Oct/07 07:08 AM ]
Resolved in SCA C and C++ Telecon Thursday, 11 October 2007
See minutes at http://www.oasis-open.org/apps/group_public/event.php?event_id=16698
Comment by Andrew Borley [ 25/Mar/08 07:19 AM ]
Issue closed in Committee Draft 01. Approved in in SCA C and C++ Telecon Thursday, 20 March 2008
See minutes at http://www.oasis-open.org/committees/event.php?event_id=16721




[CCPP-11] Choose published C C&I document URL hierarchy
Created: 02/Oct/07  Updated: 25/Mar/08

Status: Closed
Project: OASIS SCA C-CPP TC
Component/s: C specification
Affects Version/s: Version 1.1
Fix Version/s: Version 1.1

Type: Bug Priority: Major
Reporter: Andrew Borley Assigned To: David Haney
Resolution: Fixed Votes: 0


 Description   
Target: C Client and Implementation Model

Description: The OASIS template requires a that all specifications contain URLs for the current spec, previous spec, latest spec, and latest approved spec, however it doesn't specify a structure for the location of these documents, or how individual specifications should be named. The TC needs to determine what organizational structure should be used for the C and C++ specifications, along with test suites and other artifacts.

Proposal: The directory hierarchy should be coordinated with other OpenCSA TCs to ensure consistency across SCA specs.

Raised to the OASIS Service Component Architecture / C and C++ (SCA-C-C++) TC in the e-mail at http://lists.oasis-open.org/archives/sca-c-cpp/200710/msg00014.html

 Comments   
Comment by Andrew Borley [ 05/Oct/07 05:42 AM ]
Opened in SCA C and C++ Telecon Thursday, 04 October 2007
See minutes at http://www.oasis-open.org/apps/org/workgroup/sca-c-cpp/event.php?event_id=16697
Comment by Andrew Borley [ 05/Oct/07 08:05 AM ]
Apologies - public minutes for SCA C and C++ Telecon Thursday, 04 October 2007 are at http://www.oasis-open.org/committees/event.php?event_id=16697
Comment by Andrew Borley [ 01/Nov/07 11:24 AM ]
Resolved in SCA C and C++ Telecon Thursday, 01 November 2007
See minutes at http://www.oasis-open.org/committees/event.php?event_id=16701
Comment by Andrew Borley [ 25/Mar/08 07:19 AM ]
Issue closed in Committee Draft 01. Approved in in SCA C and C++ Telecon Thursday, 20 March 2008
See minutes at http://www.oasis-open.org/committees/event.php?event_id=16721




[CCPP-10] Choose published C++ C&I document URL heirarchy
Created: 02/Oct/07  Updated: 25/Mar/08

Status: Closed
Project: OASIS SCA C-CPP TC
Component/s: C++ specification
Affects Version/s: Version 1.1
Fix Version/s: Version 1.1

Type: Bug Priority: Major
Reporter: Andrew Borley Assigned To: David Haney
Resolution: Fixed Votes: 0


 Description   
Target: C++ Client and Implementation Model

Description: The OASIS template requires a that all specifications contain URLs for the current spec, previous spec, latest spec, and latest approved spec, however it doesn't specify a structure for the location of these documents, or how individual specifications should be named. The TC needs to determine what organizational structure should be used for the C and C++ specifications, along with test suites and other artifacts.

Proposal: The directory hierarchy should be coordinated with other OpenCSA specs to ensure consistency across SCA specs.

Raised to the OASIS Service Component Architecture / C and C++ (SCA-C-C++) TC in the e-mail at http://lists.oasis-open.org/archives/sca-c-cpp/200710/msg00013.html

 Comments   
Comment by Andrew Borley [ 05/Oct/07 05:42 AM ]
Opened in SCA C and C++ Telecon Thursday, 04 October 2007
See minutes at http://www.oasis-open.org/apps/org/workgroup/sca-c-cpp/event.php?event_id=16697
Comment by Andrew Borley [ 05/Oct/07 08:04 AM ]
Apologies - public minutes for SCA C and C++ Telecon Thursday, 04 October 2007 are at http://www.oasis-open.org/committees/event.php?event_id=16697
Comment by Andrew Borley [ 01/Nov/07 11:23 AM ]
Resolved in SCA C and C++ Telecon Thursday, 01 November 2007
See minutes at http://www.oasis-open.org/committees/event.php?event_id=16701
Comment by Andrew Borley [ 25/Mar/08 07:19 AM ]
Issue closed in Committee Draft 01. Approved in in SCA C and C++ Telecon Thursday, 20 March 2008
See minutes at http://www.oasis-open.org/committees/event.php?event_id=16721




[CCPP-9] Replace osoa::sca C++ namespace with OASIS namespace
Created: 02/Oct/07  Updated: 05/Mar/09

Status: Closed
Project: OASIS SCA C-CPP TC
Component/s: C++ specification
Affects Version/s: Version 1.1
Fix Version/s: Version 1.1

Type: Bug Priority: Major
Reporter: Andrew Borley Assigned To: David Haney
Resolution: Fixed Votes: 0


 Description   
Target: C++ Client and Implementation Model

Description: The C++ Client and Implementation Model currently specifies a C++ namespace of "osoa::sca". This namespace should be updated to match OASIS conventions.

Proposal: Other OASIS specs that define C++ APIs should be reviewed for any existing namespace conventions. The package name for the SCA Java C&I could also be used as a reference. Barring any other conventions, "oasis::sca" may be reasonable.

Raised to the OASIS Service Component Architecture / C and C++ (SCA-C-C++) TC in the e-mail at http://lists.oasis-open.org/archives/sca-c-cpp/200710/msg00012.html

 Comments   
Comment by Andrew Borley [ 05/Oct/07 05:41 AM ]
Opened in SCA C and C++ Telecon Thursday, 04 October 2007
See minutes at http://www.oasis-open.org/apps/org/workgroup/sca-c-cpp/event.php?event_id=16697
Comment by Andrew Borley [ 05/Oct/07 08:04 AM ]
Apologies - public minutes for SCA C and C++ Telecon Thursday, 04 October 2007 are at http://www.oasis-open.org/committees/event.php?event_id=16697
Comment by Andrew Borley [ 30/Apr/08 10:52 AM ]
Resolved in SCA C and C++ Telecon Thursday, 24th April 2008
See minutes at http://www.oasis-open.org/committees/event.php?event_id=16726
Comment by Bryan Aupperle [ 05/Mar/09 01:15 PM ]
Issue closed in Committee Draft 02. Approved in in SCA C and C++ Telecon Thursday, 5 February 2009.
See minutes at http://www.oasis-open.org/committees/event.php?event_id=19318




[CCPP-8] Replace osoa.org schema namespace with OASIS namespace in C C&I
Created: 02/Oct/07  Updated: 25/Mar/08

Status: Closed
Project: OASIS SCA C-CPP TC
Component/s: C specification
Affects Version/s: Version 1.1
Fix Version/s: Version 1.1

Type: Bug Priority: Major
Reporter: Andrew Borley Assigned To: David Haney
Resolution: Fixed Votes: 0


 Description   
Target: C Client and Implementation Model

Description: The C Client and Implementation Model currently specifies a target namespace of "http://www.osoa.org/xmlns/sca/1.0". This namespace should be updated to match OASIS conventions. The namespace should also be updated to match the current spec version number.

Proposal: None, however the namespace used should be coordinated with the other OpenCSA TCs. The OpenCSA group also needs to determine if each spec will have it's own namespace, or if there will be a common namespace for all SCA specs.

Raised to the OASIS Service Component Architecture / C and C++ (SCA-C-C++) TC in the e-mail at http://lists.oasis-open.org/archives/sca-c-cpp/200710/msg00011.html

 Comments   
Comment by Andrew Borley [ 05/Oct/07 05:41 AM ]
Opened in SCA C and C++ Telecon Thursday, 04 October 2007
See minutes at http://www.oasis-open.org/apps/org/workgroup/sca-c-cpp/event.php?event_id=16697
Comment by Andrew Borley [ 05/Oct/07 08:04 AM ]
Apologies - public minutes for SCA C and C++ Telecon Thursday, 04 October 2007 are at http://www.oasis-open.org/committees/event.php?event_id=16697
Comment by Andrew Borley [ 01/Nov/07 11:23 AM ]
Resolved in SCA C and C++ Telecon Thursday, 01 November 2007
See minutes at http://www.oasis-open.org/committees/event.php?event_id=16701
Comment by Andrew Borley [ 25/Mar/08 07:19 AM ]
Issue closed in Committee Draft 01. Approved in in SCA C and C++ Telecon Thursday, 20 March 2008
See minutes at http://www.oasis-open.org/committees/event.php?event_id=16721




[CCPP-7] Annotations are needed to specify intents
Created: 02/Oct/07  Updated: 25/Mar/08

Status: Closed
Project: OASIS SCA C-CPP TC
Component/s: C specification
Affects Version/s: Version 1.1
Fix Version/s: Version 1.1

Type: Bug Priority: Major
Reporter: Andrew Borley Assigned To: Bryan Aupperle
Resolution: Fixed Votes: 0


 Description   
Target: C Client and Implementation Model/C Annotations

Description: The policy framework defines a way for intents to be attached to various SCA constructs including interfaces and operations. These intents can be attached in the SCDL using a requires attribute. There is no way for a C developer to define required intents without authoring SCDL directly.

Proposal: Add an @Requires annotation that can be used with interfaces and methods. This annotation would include a list of intents to be applied. We may also want some additional specific annotations like @Conversational.

Raised to the OASIS Service Component Architecture / C and C++ (SCA-C-C++) TC in the e-mail at http://lists.oasis-open.org/archives/sca-c-cpp/200710/msg00007.html

 Comments   
Comment by Andrew Borley [ 05/Oct/07 05:41 AM ]
Opened in SCA C and C++ Telecon Thursday, 04 October 2007
See minutes at http://www.oasis-open.org/apps/org/workgroup/sca-c-cpp/event.php?event_id=16697
Comment by Andrew Borley [ 05/Oct/07 08:04 AM ]
Apologies - public minutes for SCA C and C++ Telecon Thursday, 04 October 2007 are at http://www.oasis-open.org/committees/event.php?event_id=16697
Comment by Andrew Borley [ 08/Nov/07 10:36 AM ]
Resolved in SCA C and C++ Telecon Thursday, 08 November 2007
See minutes at http://www.oasis-open.org/committees/event.php?event_id=16702
Comment by Andrew Borley [ 25/Mar/08 07:19 AM ]
Issue closed in Committee Draft 01. Approved in in SCA C and C++ Telecon Thursday, 20 March 2008
See minutes at http://www.oasis-open.org/committees/event.php?event_id=16721




[CCPP-6] Annotations are needed to control mapping from C to WSDL
Created: 02/Oct/07  Updated: 22/Jan/09

Status: Closed
Project: OASIS SCA C-CPP TC
Component/s: C specification
Affects Version/s: Version 1.1
Fix Version/s: Version 1.1

Type: Bug Priority: Major
Reporter: Andrew Borley Assigned To: Bryan Aupperle
Resolution: Duplicate Votes: 0


 Description   
Target: C Client and Implementation Model/C Annotations

Description: There will be circumstances where it will be necessary to modify the default mapping from C to WSDL. Examples: where the method name or a parameter name could be more descriptive in the WSDL or the type of a parameter may be mapped to an existing define type.

Proposal: None at this time.

Raised to the OASIS Service Component Architecture / C and C++ (SCA-C-C++) TC in the e-mail at http://lists.oasis-open.org/archives/sca-c-cpp/200710/msg00008.html

 Comments   
Comment by Andrew Borley [ 05/Oct/07 05:41 AM ]
Opened in SCA C and C++ Telecon Thursday, 04 October 2007
See minutes at http://www.oasis-open.org/apps/org/workgroup/sca-c-cpp/event.php?event_id=16697
Comment by Andrew Borley [ 05/Oct/07 08:04 AM ]
Apologies - public minutes for SCA C and C++ Telecon Thursday, 04 October 2007 are at http://www.oasis-open.org/committees/event.php?event_id=16697
Comment by Andrew Borley [ 22/Jan/09 10:10 AM ]
Closed as duplicate of CCPP-42 in SCA C and C++ Telecon Thursday, 22nd January 2009
See minutes at http://www.oasis-open.org/apps/group_public/event.php?event_id=19316




[CCPP-5] Annotations are needed to control mapping from WSDL to C
Created: 02/Oct/07  Updated: 22/Jan/09

Status: Closed
Project: OASIS SCA C-CPP TC
Component/s: C specification
Affects Version/s: Version 1.1
Fix Version/s: Version 1.1

Type: Bug Priority: Major
Reporter: Andrew Borley Assigned To: Bryan Aupperle
Resolution: Duplicate Votes: 0


 Description   
Target: C Client and Implementation Model/C Annotations

Description: There will be circumstances where it will be necessary to modify the default mapping from WSDL to C. Examples: where the operation name or a message element name is not a valid C name or the type of a message element can be more efficiently be manipulated with a non-default mapping.

Proposal: SDO defines a way to do this. We should examine what has been done there.

Raised to the OASIS Service Component Architecture / C and C++ (SCA-C-C++) TC in the e-mail at http://lists.oasis-open.org/archives/sca-c-cpp/200710/msg00009.html

 Comments   
Comment by Andrew Borley [ 05/Oct/07 05:41 AM ]
Opened in SCA C and C++ Telecon Thursday, 04 October 2007
See minutes at http://www.oasis-open.org/apps/org/workgroup/sca-c-cpp/event.php?event_id=16697
Comment by Andrew Borley [ 05/Oct/07 08:04 AM ]
Apologies - public minutes for SCA C and C++ Telecon Thursday, 04 October 2007 are at http://www.oasis-open.org/committees/event.php?event_id=16697
Comment by Andrew Borley [ 22/Jan/09 10:09 AM ]
Closed as duplicate of CCPP-42 in SCA C and C++ Telecon Thursday, 22nd January 2009
See minutes at http://www.oasis-open.org/apps/group_public/event.php?event_id=19316




[CCPP-4] Replace osoa.org schema namespace with OASIS namespace in C++ C&I
Created: 02/Oct/07  Updated: 25/Mar/08

Status: Closed
Project: OASIS SCA C-CPP TC
Component/s: C++ specification
Affects Version/s: Version 1.1
Fix Version/s: Version 1.1

Type: Bug Priority: Major
Reporter: Andrew Borley Assigned To: David Haney
Resolution: Fixed Votes: 0


 Description   
Target: C++ Client and Implementation Model

Description: The C++ Client and Implementation Model currently specifies a target namespace of "http://www.osoa.org/xmlns/sca/1.0". This namespace should be updated to match OASIS conventions. The namespace should also be updated to match the current spec version number.

Proposal: None, however the namespace used should be coordinated with the other OpenCSA TCs. The OpenCSA group also needs to determine if each spec will have it's own namespace, or if there will be a common namespace for all SCA specs.

Raised to the OASIS Service Component Architecture / C and C++ (SCA-C-C++) TC in the e-mail at http://lists.oasis-open.org/archives/sca-c-cpp/200710/msg00010.html

 Comments   
Comment by Andrew Borley [ 05/Oct/07 05:40 AM ]
Opened in SCA C and C++ Telecon Thursday, 04 October 2007
See minutes at http://www.oasis-open.org/apps/org/workgroup/sca-c-cpp/event.php?event_id=16697
Comment by Andrew Borley [ 05/Oct/07 08:04 AM ]
Apologies - public minutes for SCA C and C++ Telecon Thursday, 04 October 2007 are at http://www.oasis-open.org/committees/event.php?event_id=16697
Comment by Andrew Borley [ 01/Nov/07 11:23 AM ]
Resolved in SCA C and C++ Telecon Thursday, 01 November 2007
See minutes at http://www.oasis-open.org/committees/event.php?event_id=16701
Comment by Andrew Borley [ 25/Mar/08 07:19 AM ]
Issue closed in Committee Draft 01. Approved in in SCA C and C++ Telecon Thursday, 20 March 2008
See minutes at http://www.oasis-open.org/committees/event.php?event_id=16721




[CCPP-3] Annotations are needed to control mapping from C++ to WSDL
Created: 01/Oct/07  Updated: 22/Jan/09

Status: Closed
Project: OASIS SCA C-CPP TC
Component/s: C++ specification
Affects Version/s: None
Fix Version/s: Version 1.1

Type: Bug Priority: Major
Reporter: Andrew Borley Assigned To: David Haney
Resolution: Duplicate Votes: 0


 Description   
Target: C++ Client and Implementation Model/C++ Annotations

Description: There will be circumstances where it will be necessary to modify the default mapping from C++ to WSDL. Examples: where the method name or a parameter name could be more descriptive in the WSDL or the type of a parameter may be mapped to an existing define type.

Proposal: None at this time.

Raised to the OASIS Service Component Architecture / C and C++ (SCA-C-C++) TC in the e-mail at http://lists.oasis-open.org/archives/sca-c-cpp/200709/msg00030.html

 Comments   
Comment by Andrew Borley [ 05/Oct/07 05:40 AM ]
Opened in SCA C and C++ Telecon Thursday, 04 October 2007
See minutes at http://www.oasis-open.org/apps/org/workgroup/sca-c-cpp/event.php?event_id=16697
Comment by Andrew Borley [ 05/Oct/07 08:04 AM ]
Apologies - public minutes for SCA C and C++ Telecon Thursday, 04 October 2007 are at http://www.oasis-open.org/committees/event.php?event_id=16697
Comment by Andrew Borley [ 22/Jan/09 10:09 AM ]
Closed as duplicate of CCPP-17 in SCA C and C++ Telecon Thursday, 22nd January 2009
See minutes at http://www.oasis-open.org/apps/group_public/event.php?event_id=19316




[CCPP-2] Annotations are needed to control mapping from WSDL to C++
Created: 01/Oct/07  Updated: 22/Jan/09

Status: Closed
Project: OASIS SCA C-CPP TC
Component/s: C++ specification
Affects Version/s: None
Fix Version/s: Version 1.1

Type: Bug Priority: Major
Reporter: Andrew Borley Assigned To: David Haney
Resolution: Duplicate Votes: 0


 Description   
Target: C++ Client and Implementation Model/C++ Annotations

Description: There will be circumstances where it will be necessary to modify the default mapping from WSDL to C++. Examples: where the operation name or a message element name is not a valid C++ name or the type of a message element can be more efficiently be manipulated with a non-default mapping.

Proposal: SDO defines a way to do this. We should examine what has been done there.

Raised to the OASIS Service Component Architecture / C and C++ (SCA-C-C++) TC in the e-mail at http://lists.oasis-open.org/archives/sca-c-cpp/200709/msg00032.html

 Comments   
Comment by Andrew Borley [ 05/Oct/07 05:40 AM ]
Opened in SCA C and C++ Telecon Thursday, 04 October 2007
See minutes at http://www.oasis-open.org/apps/org/workgroup/sca-c-cpp/event.php?event_id=16697
Comment by Andrew Borley [ 05/Oct/07 08:03 AM ]
Apologies - public minutes for SCA C and C++ Telecon Thursday, 04 October 2007 are at http://www.oasis-open.org/committees/event.php?event_id=16697
Comment by Andrew Borley [ 22/Jan/09 10:08 AM ]
Closed as duplicate of CCPP-17 in SCA C and C++ Telecon Thursday, 22nd January 2009
See minutes at http://www.oasis-open.org/apps/group_public/event.php?event_id=19316




[CCPP-1] Annotations are needed to specify intents
Created: 01/Oct/07  Updated: 25/Mar/08

Status: Closed
Project: OASIS SCA C-CPP TC
Component/s: C++ specification
Affects Version/s: None
Fix Version/s: Version 1.1

Type: Bug Priority: Major
Reporter: Andrew Borley Assigned To: David Haney
Resolution: Fixed Votes: 0


 Description   
Target: C++ Client and Implementation Model/C++ Annotations

Description: The policy framework defines a way for intents to be attached to various SCA constructs including interfaces and operations. These intents can be attached in the SDCL using a requires attribute. There is no way for a C++ developer to define required intents without authoring SCDL directly.

Proposal: Add an @Requires annotation that can be used with interfaces and methods. This annotation would include a list of intents to be applied. We may also want some additional specific annotations like @Conversational.

Raised to the OASIS Service Component Architecture / C and C++ (SCA-C-C++) TC in the e-mail at http://lists.oasis-open.org/archives/sca-c-cpp/200709/msg00031.html

 Comments   
Comment by Andrew Borley [ 05/Oct/07 05:37 AM ]
Opened in SCA C and C++ Telecon Thursday, 04 October 2007
See minutes at http://www.oasis-open.org/apps/org/workgroup/sca-c-cpp/event.php?event_id=16697
Comment by Andrew Borley [ 05/Oct/07 08:03 AM ]
Apologies - public minutes for SCA C and C++ Telecon Thursday, 04 October 2007 are at http://www.oasis-open.org/committees/event.php?event_id=16697
Comment by Andrew Borley [ 01/Nov/07 11:24 AM ]
Resolved in SCA C and C++ Telecon Thursday, 01 November 2007
See minutes at http://www.oasis-open.org/committees/event.php?event_id=16701
Comment by Andrew Borley [ 25/Mar/08 07:19 AM ]
Issue closed in Committee Draft 01. Approved in in SCA C and C++ Telecon Thursday, 20 March 2008
See minutes at http://www.oasis-open.org/committees/event.php?event_id=16721




Generated at Wed Feb 08 07:55:04 CST 2012 by Bryan Aupperle using JIRA 187.