Revision: Core V3 Plan

This page tracks proposals for and issues about the next version of the OSLC Core specification, Version 3.0. The information and references on this page will guide the development of a schedule, changes and additions in V3. This page is intended to be a starting point for such discussions, a place to evolve those discussion and define how to get to specification.

Themes for V3

Here are possible themes to help us prioritize proposals for additions and changes to V3:

• Adoption - evaluate what tasks can be done to help with general adoption of specs - tutorials, SDKs, supporting docs to spec, validating the level of OSLC support through a scale
• Simplification - along the same theme of adoption, look for ways to continue to simplify both the number of concepts, model and overall complexity of OSLC, reducing the technical barriers to adoption. This includes alignment with other standards bodies like W3C around linked data patterns.
• Community Growth - ways to broaden the community and solidify OSLC as an independent entity opening the door for larger community
• DevOps - expanding the reach of ALM into operations which also has some implications of OSLC support strictly within Ops
• PLM - exposes specification and guidance on spec usage for PLM
• ALM continued - looking at additional scenarios needed. Think of it as a continued evolution of what we have today. This includes cross-cutting capabilities such as partial update.

Planned Content for V3

See OSLC Core V3 Outline

Timeline for V3

Here is a proposed roadmap and timetable for Core V3

2H 2012 - Convergence draft, implementation occurring and in finalization

1H 2013 - Finalized draft - multiple implementation feedback, interoperable spec

Working Documents

• OSLC Core V3 Outline

Specification requirements

During the development of V3 Core, it would be an ideal time to evaluate the past specification structure and determine what would be appropriate for current needs of V3 specs.

1. A Core specification capability should be mostly independent and can be adopted by dependent specification and implementations independently.
2. Clients should be able to have a way to discover servers’ supported Core specification capabilities
   1. Clients should be able to easily discover needed capabilities and resource types supported by a server to satisfy an integration scenario
   2. A class of clients want to ask the question: Is this a CM x.x server where I can submit bugs?
   3. A class of clients want to ask the question: Is this a Core x.x server where I can do certain things?
3. Most domain specifications require a common profile of Core specifications, therefore it may be useful to streamline this: i.e. not have to repeat the same specification requirements multiple times
4. Need a minimal way to add additional domain vocabularies or change them without full specification process
   1. Guidance on providing compatible changes and ways to ensure vocabularies are designed initially this way
   2. Domain vocabularies need to have their own unique specification timetable

Discussion items

Discussion about requirements for specification authoring:

• What worked and didn’t work with 2.0?
• What is really needed for developing core specs, domain specs and vocabularies?
• Can we use a more declarative way of defining our specifications?

Discovery/spec needs:

• What is needed by clients to learn a provider supports a domain?
• Is it best for a client to receive a URI that has associated documentation (specs) that articulates

Proposals / Issues to consider for post V2

These are proposals for things that could be included in V3 or developed as separate guidance in the same timeframe as V3.

• Add compliance section to the spec
• Address ambiguities in Service Discovery / Description model
• Guidance for Query Capabilities
• Core simplifications
• Multi-typed Resources
• Partial Update

Stretch goals:

• Resource Centric Editors and Views
• Approvals process enactment
• What is a system
• Versioning
• Baselining
• Eventing
• Comments and Discussions
• Modeling Hierarchies

See also Possible OSLC priorities and themes for 2011

Backlog of issues from V2

These are issues that we deferred when we were developing OSLC Core V2.

1. OPEN oslc:ResponseInfo should be renamed to oslc:Page
2. OPEN oslc:paging should be renamed to oslc:pagination
3. OPEN use rdf:next instead of oslc:nextPage
4. OPEN Need formal grammar for Query Syntax, re: “syntax is formally defined using a common extended form of BNF” (JA, Dec. 9, 2010)
   • Response: added reference to wikipedia definition of EBNF. We do need a better grammar and prefer to use ANTLR since it is machine readable and supported by tools, but we will defer until a later version of the Core spec (DaveJohnson, Dec. 17, 2010)
5. OPEN Compact html representations - Should we add Core Spec guidance on protocol for UI rendering of hovers on links? The way Jazz does this is here https://jazz.net/wiki/bin/view/Sandbox/CompactRenderingV1P1 (ScottBosworth, 03/04/2010)
   • Response Yes but as separate guidance (DaveJohnson 03/18/2010)
6. OPEN Migration Guidance need guidance of how existing 1.0 specs can migrate (IanGreen, 03/03/2010)
   • Response Core WG will provide separate guidance and an Example OSLC Domain Spec as (DaveJohnson 03/18/2010)
7. OPEN Query Filters. The Jazz notion of “Query Filters” is very useful, implementations of it exist and it should be included in the OSLC Core, documentation is here https://jazz.net/wiki/bin/view/Main/CALMFilters (from ErichGamma via DaveJohnson, 03/05/2010)
8. OPEN Guidance on Rich Text. Should we really mandate XHTML for rich text fields? What about systems that support wiki syntax or just HTML?
   • Response Make common properties dc:title and dc:description XML literal with type XHTML and recommend XHTML for rich text interchange, but beyond that no mandate. Also a) The value of the dc:title property should be a single line of text, so it should be restricted to be valid content of a <span> element and b) The value of the dc:description property may be multiple lines of text, so it should be restricted to be valid content of a <div> element. %ORANGE%Once that is done in spec, mark this as deferred to ensure that we have some guidance on how to deal with text fields, rich text fields and wiki syntax%ENDCOLOR% (DaveJohnson 04/07/2010)
9. OPEN Extended Properties. Services should specify whether each property is an extended property or not. In services that support selective properties, extended properties are only provided in resources that with oslc.properties specified. (DaveJohnson 04/12/2010)
   • Response: Added the notion of an Extended property to the OSLC Defined Resource section and a oslc:extended property to the Resource Shape’s oslc:Property resource to convey this info in resource shapes (DaveJohnson 04/16/2010)
   • Response: deferred this for consideration later (DaveJohnson 07/12/2010)
10. OPEN Query by Post. Query Capability and oslc:queryBase: need a way to allow for POST by Query to get around the query-URL-too-long problem that implementations face on commonly used web servers.
    • See also http://open-services.net/pipermail/oslc-core_open-services.net/2011-March/000892.html
11. OPEN Delegated UI Dialogs. When using the post message (#oslc-postmessage-1.0) and window name (#oslc-windowname-1.0) protocols in pages containing sections, anchors in the URL cannot be used. Consider using a header for the protocol.
12. OPEN Delegated UI Dialogs prefill for creation, no shapes are provided to help guide clients on what can be prefilled (SteveSpeicher 8/22/2011)
    • Response: (possible) add shapes to creation dialogs
13. OPEN PATCH support need to define PATCH document syntax and clarify semantics (SteveSpeicher 9/06/2011)
14. OPEN Conceptual model need to define a conceptual model of all OSLC domains to help define a “big picture” of inventory of resource types and properties (SteveSpeicher 9/06/2011)