History   View   Links to this page Revision from: 2014 April 17 | 08:33 am
This is the revision from 2014 April 17 at 08:33 am   View the current live version of the article.

This section captures the issues raised via review comments on:

Issues are organized via the specification outline.

Note: dates below use US format (mm/dd/yyyy)

Here’s what the states mean:

  • OPEN - indicates that we have no response for the issue yet
  • RESOLVED - indicates that we have a response that we believe resolves the issue
    • RESOLVED - indicates it is resolved as by above definition and edits in the draft specification have been made.
  • CLOSED - issue has been resolved and the resolution has been reviewed by the workgroup
  • DEFERRED - indicates that issue will be addressed in guidance after the specification converges
  • TABLED - indicates that issue will be reconsidered at some later but unspecified date

Issues during draft development

  1. TABLED - Suggestion from JohnArwe: Move the compliance table to an appendix and reference it here. Different from what other specs do but potentially more friendly for casual readers.
    • The compliance table is still in the body - but it has been updated to improve readability. (MichaelFiedler, 16 Feb 2012)
  2. CLOSED - The Core specification makes Query Capabilities and the OSLC Query Syntax MAY items. Currently, they are defined in Automation as MUST (cf. CM and QM specification). Do we want to relax these requirements for Automation? or keep them as MUST?
    • Workgroup consensus is that they remain as MUST requirements.
  3. CLOSED - The current specification defines an oslc_auto:automationinstructions attribute on Automation Plans. Intent is to capture (reference or inline) a service provider specific resource representing how an automation will be executed. This could be a script, binary, text instructions representing what the automation will do, etc. Is this required for the V2 scenarios.
    • Workgroup consensus is that these instructions are not required for the scenarios in V2 of the specification.
  4. CLOSED - State enumerations. There are at least three attributes in the automation request and result which could have an enumerated set of values: oslc_auto:status, oslc_auto:desiredStatus and oslc_auto:verdict. Does the specification need to specify the legal values for these attributes? See the CM spec’s definition of state predicate properties for a possible approach: CmSpecificationV2#State_Predicates and CmSpecificationV2.
    • 21 Feb 2012: Specification updated with state predicates for oslc_auto:verdict. Still open: Are state predicates needed for oslc_auto:state and oslc_auto:desiredState?
    • 21 March 2012: Specification updated again - changed state and verdict attributes to use references to either automation or service provider definitions of states and verdicts.
    • 2 April 2012: Workgroup discussion on 22 March led to a discussion on strengthening the wording to assist consumers. Proposed: Implementations MUST use verdict values defined by the OSLC Automation specification. Implementations MUST include at least one state defined by the OSLC Automation specification and additional states defined by the provider MAY be included.
    • 5 April 2012: Workgroup agreed to make use of at least one Automation verdict and state a MUST. Providers can additionally use their own vocabularies.
  5. CLOSED - the relationship from an Automation Request to an Automation Plan was recently changed from exactly-one to zero-to-one. Objections? There seems to be a possible use case where you create the request in some holding state and later hook it to a specific test plan and move the desired state to ready-to-run state. Too advanced for V2?
    • Workgroup consensus was that Automation Request -> Plan and Automation Result -> Plan should be exactly-one. Spec updated
  6. CLOSED - Automation Results currently refer to exactly-one Automation Request and exactly-one Automation Plan. Should these be zero-to-one. Can results be created in the absence of plans?
    • Workgroup consensus was that Automation Request -> Result should be zero-to-one and Automation Result -> Plan should be exactly-one. Spec updated
  7. CLOSED - Need the workgroup to review the delegated UI table and come to agreement on MUST/SHOULD/MAY for each artifact type.
    • 21 Feb 2012 - Reviewed by workgroup - no disagreements raised
  8. CLOSED - Parameter Definitions have been partially restored in the spec (Description of them, HTTP support table). Should they be a separate resource type or just left as defined in the Automation Plan with a range of oslc:Property?
    • 21 March 2012 - Created Minimal parameter definition to show what the minimum definition of a parameter in an automation plan looks like
    • 19 April 2012 - Resolved - it will not be a separate resource. It will be in-line and have a range of oslc:Property.
  9. CLOSED - DELETE support omitted from HTTP table.
    • 04 April 2012 - Added DELETE to the table and a proposed statement on the specification not constraining DELETE. Need to discuss if additional wording on responsibility for deletion is needed in workgroup.
    • 05 April 2012 - Amended DELETE to be a SHOULD and added statement that DELETE should be supported wherever creation is.
  10. CLOSED - Scenario for a consumer finding the automation result associated with its request seems burdensome to simple consumers/providers with limited query support.
  11. CLOSED - Should OSLC Query Syntax support be a MUST in the Automation Specification?
    • 12 April 2012 - Discussion ongoing in the workgroup. Strawman proposal to make it a SHOULD incorporated in the spec for review.
    • Resolution: Query and oslc.properties are now SHOULD requirements
  12. CLOSED - Should PUT support be a MUST in the Automation Specification?
    • 18 April 2012 - Relax the MUST to a SHOULD
  13. CLOSED - oslc_auto:parameter is used to refer to different resources in Automation Plans vs. Requests and Results. Different attribute names would make the vocabulary clearer.
    • 04 April 2012 - Updated specification with proposal to use oslc_auto:parameterDefinition in the plan and use oslc_auto:initialParameter consistently in the request and result.
    • Resolution: Parameter Definitions are not separate resources. They are predicates on Automation Plans with a range of oslc:Property
  14. CLOSED - Mailing list thread on value of oslc:propertyDefinition in an automation plan parameterDefinition. See: http://open-services.net/pipermail/oslc-automation_open-services.net/2012-April/000128.html
    • Resolution: Specification updated to clarify input and output parameters in Automation Requests and Results
    • 12 April 2012 - Discussion ongoing in the workgroup. Proposals listed in AutomationMeetings20120412
  15. CLOSED - Mailing list thread on parameters on the automation resources - need for clarification and possible attribute renaming in the specifcation. See: http://open-services.net/pipermail/oslc-automation_open-services.net/2012-April/000128.html
  16. CLOSED - Should links between Automation Requests and Automation Plans be bi-directional? It would be useful in some scenarios (limited query support and/or synchronous scenarios) for the Automation Request to contain a link to its Automation Result(s). Bi-directional link definitions are not the norm in OSLC but might be of benefit for these automation resources.
    • 19 April 2012 - Discussion in workgroup failed to identify a scenario which is broken without bi-directional links. Agreement to continue with uni-directional links.

Issues after V2 Finalization

  1. DEFERRED - Automation enumerations for states and verdicts are currently terms in the spec when they should be instances of rdfs:Class. See: http://open-services.net/pipermail/oslc-automation_open-services.net/2013-January/000355.html
  2. RESOLVED - The V2 specification states “OSLC Automation service providers MUST provide a oslc:serviceProvider property for their defined resources that will be the URI to a Service Provider Resource.” However, in the Automation resources, oslc:serviceProvider has a cardinality of zero-or-many. Proposal: Change the wording to “MAY provide….”.
    • 21 Feb 2013 - after discussion, the agreement is to change “service providers MUST provide a oslc:serviceProvider property” to “it is RECOMMENDED that service providers provide a oslc:serviceProvider property”. Spec has been updated accordingly.
  3. RESOLVED - The V2 specification description of oslc_auto:producedByAutomationRequest has a probable typo in its description. It says: “Automation Request which produced the Automation Result. It is likely that the target resource will be an oslc_auto:AutomationResult but that is not necessarily the case.” The target resource would likely be oslc_auto:AutomationRequest.
    • 2013-06-27 meeting: The target resource should be oslc_auto:AutomationRequest.
  4. RESOLVED - The OSLC Automation terms “Plans”, “Requests” and “Results” are not always suitable for display to all users, as they would not be aware of their OSLC meanings. There is no guidance on what wording to use when presenting these to users. The separate sub-domains might have different terminology that is appropriate.
  5. RESOLVED - Existing text from the description of contribution: “The recommended attributes beyond the contribution itself are dcterms:title, dcterms:description and dcterms:type to provide a description of the contribution which would be appropriate for display in a simple UI for an automation result.” dcterms:type should be rdf:type. Dublin Core specifically deprecates the use of dcterms:type in RDF contexts. Mailing list thread
    • 7 Nov 2013 - after discussion, agreed to change dcterms:type to rdf:type in 2.0 spec.
    • 13 Dec 2013 - Automation 2.0 specification updated.
  6. RESOLVED - Automation Result links to ParameterInstance had hrefs that omitted the R
    • 30 Oct 2013 - Automation 2.0 specification updated.
  7. OPEN - Is the definition of ParameterInstance wrt data types ill-defined? Mailing list thread
    • 7 Nov 2013 - after discussion, it was agreed to change the wording to “The value may be an RDF literal or a resource. If the value type is a RDF literal, then it Should be a RDF typed literal.”
    • 13 Dec 2013 - Automation 2.0 specification updated.
    • 16 Dec 2013 - question raised about the use of the term “value type”, so issue remains open.
  8. RESOLVED - 6 Mar 2014 - On the vocabulary wiki page the “in RDFS format” link is to itself, not to the rdf/xml file. Mailing list thread
    • 11 Mar 2014 - Automation vocabulary updated.
  9. RESOLVED - 6 Mar 2014 - The vocabulary rdf/xml file incorrectly defines the inputParameter property on the URI “http://open-services.net/ns/auto#initialParameter”. Mailing list thread
    • 11 Mar 2014 - Automation vocabulary updated.
  10. RESOLVED - 6 Mar 2014 - The vocabulary rdf/xml file incorrectly defines the “passed” state on the URI “http://open-services.net/ns/auto#pass”. Mailing list thread
    • 11 Mar 2014 - Automation vocabulary updated.
  11. RESOLVED - 6 Mar 2014 - The vocabulary rdf/xml file incorrectly defines the “outputParameter” property on the URI “http://open-services.net/ns/auto#additionalParameter”. Mailing list thread
    • 11 Mar 2014 - Automation vocabulary updated.
  12. OPEN - Asynchronous and Synchronous Automation Execution section refers to oslc_auto:verdict=oslc_auto:incomplete, but State and verdict properties does not mention this value. Does it mean oslc_auto:unavailable?
  13. OPEN - The Query capabilities section contain a broken link in the phrase “service providers SHOULD use the default properties defined in OSLC Core RDF/XML Examples to contain the result.” It is likely that this is what has been moved here, but it is still not clear what properties this is referring to. (Also affects version 2.1.)
    • Raised on 17 April 2014
  14. OPEN - The service provider resource section there is a broken link to http://open-services.net/bin/view/Main/OslcCoreSpecification#Service_Provider_Catalog_Resources. This should probably be http://open-services.net/bin/view/Main/OslcCoreSpecification#Resource_Service_Provider_Catalo.
    • Raised on 17 April 2014
    • Spec changed 17 April 2014