Dave, I think 1 and 2 are the right priorities now. We should be promoting the adoption of the current specs.
Regards, ___________________________________________________________________________ Arthur Ryman, PhD, DE Chief Architect, Project and Portfolio Management IBM Software, Rational Markham, ON, Canada | Office: 905-413-3077, Cell: 416-939-5063 From: Dave <[email protected]> To: [email protected], [email protected], [email protected], [email protected], [email protected], [email protected], [email protected], oslc-core <[email protected]>, [email protected], [email protected], [email protected], [email protected] Date: 10/05/2010 09:36 AM Subject: [oslc-core] Possible OSLC priorities and themes for 2011 Sent by: [email protected] Hello OSLC workgroups and community: Now that the OSLC v2 specs are finalizing we need think about what are the next priorities for the OSLC community. Based on feedback from the the Core workgroup and others, I've put together a list of possible priorities for us to consider. Three themes: 1) Adoption of specs: these are things that help folks adopt OSLC, both users and consumers. This includes tutorials, documentation, clients, test suites and reference implementations. 2) Guidance on using specs: the development of Guidance on specific topics needed by one or more OSLC domains, things that can be accomplished by applying the current specs, RDF and HTTP. 3) New specifications: these are new features that we need in the Core or domain specs, things that require new specification text to be developed. We'd love your feedback. What do you think of the items below? Can you think of new priorities that can help us with the three themes above? Are these the correct three themes to address and where should we put our emphasis as we head into 2011? Please respond here on this email thread and I'll do my best to capture the results. Thanks, Dave Possible OSLC 2010 - 2011 priorities and themes --- 1) Adoption Development of existing Test Suites The OSLC Core workgroup is not going to write code together, but we can play a part in helping to design test suites, advising teams creating them and possibly approving or endorsing test suites. Development Reference implementations The Core is not going to write an RI either, but we can play a part in helping to design test suites, advising teams creating them and possibly approving or endorsing test suites. --- 2) Guidance Guidance on Attachments In several OSLC domain there are use cases where some unmodifiable resource, e.g. an uploaded screenshot image, must be stored and property-values about that resource must be stored as well, but cannot be added to the resource. There are several patterns for this, one in AtomPub protocol and one in the OSLC Asset Management spec and there are others. We should explore the alternatives, the pros and cons of each and then issue guidance. Guidance on Hierarchical URLs We need stable and opaque URLs for all OSLC resources, constraints that seem to rule out embedding any sort of hierarchy into URLs, but there are cases where hierarchies are needed, for example in Asset Management, where artifacts may be web pages and associated CSS or JavaScript resources that reference each other with relative URLs. We should explore the alternatives, the pros and cons of each and then issue guidance. Guidance on Staging URLs We need stable and opaque URLs for all OSLC resources, constraints that seem to rule out the notion of staging URLs, but this notion is needed in Asset Management where software releases "go live" only after all resources are in place. We should explore the alternatives, the pros and cons of each and then issue guidance. Guidance on Multi-topic resources There will be cases where a resource is of multiple rdf:types and we have no guidance on how this situation should be handled. The Core workgroup should explore the issue, understand the issues an issue guidance in this topic. Guidance on best practices for domain workgroups extending the OSLC Core spec. --- 3) New specifications Standardization of SPARQL Partial Update Resource update is an important feature and while PUT works, it can be dangerous and in some cases inefficient. We need a way to update specific property values of a resource in a targeted way and we should work with an existing W3C workgroup, if possible, to address this rather than inventing our own new protocol. Standardization of JSON/RDF A growing number of OSLC specifications require a JSON representation and while we have a simple JSON representation that can be used to represent OSLC defined resources, it is non-standard and certainly not perfect. We need a standard way to represent RDF in JSON and we should work with ongoing efforts at W3C or other places to help create one. Seed List or other approach for Distributed Search In integrating ALM/PLM systems it is useful to be able to crawl and index resources from across multiple systems and domains. The OSLC Core workgroup should seek a standard way to enable this, explore alternatives and create an OSLC Core spec for distributed search/query indexing. Specification for Eventing In integration of ALM/PLM systems, there is a need to allow one system to register for events with one system and then receive notification whenever a build is created, or a new defect is reported. There are a number of techniques for enabling this including RSS/Atom feeds, trackbacks and web hooks. We should explore the alternatives, the pros and cons of each and then create a specification for OSLC Core Eventing. Specification for Baselining In integrating ALM/PLM systems, there is a need to allow resources across multiple systems to be baselined or "tagged" as part of a product release, integration point or branch point. We should explore the alternatives, the pros and cons of each and then create a specification for OSLC Core Baselining. _______________________________________________ Oslc-Core mailing list [email protected] http://open-services.net/mailman/listinfo/oslc-core_open-services.net
