I find this fairly hard to parse. Keeping conflicting information interleaved in the same document makes it very vulnerable to unintended readings. (Example: It shall support ... NOTE: ...shall not be ... . Proposed to rescind this as per the Q&A below at 11/11 ")
Comment 1: > Versions of a base resource have a type of Resource Version I think I understand the intent. I know I don't like what this does to the type space (doubles its size for anything versioned). It also brings up a spec authoring problem similar to what I asked about reverse links - since the "ResourceVersion" types must be defined, "adding" version capability to an already-defined resource (like those in AM) requires opening up the AM spec; new specs either have to add "ResourceVersion" types speculatively (in advance of scenarios) to avoid the need to rev them later, or pay the time delay and adoption implication costs of revving the specs to add versioning afterward. That seems fairly easily avoidable in RDF too -- define a single Version resource pretty much as you have it, and just compose it into any versioned instances regardless of their type. Using the second resource [2] in your Examples table [1], the changes would be: 1 - <oslc_am:ResourceVersion rdf:about=" http://localhost:8080/tcua-oslc/resourceversion/Tm_ZkV3LQyYmUC";> ... becomes oslc_am:Resource, same as the base 2 - <rdf:type rdf:resource="http://open-services.net/ns/am#ResourceVersion "/> ... becomes .../core#Version (the /am#Resource rdf type is implied by the oslc_am:Resource parent element in this XML example, it could also be rendered explicit without harm). Clients aware of Versions can test for <rdf:type rdf:resource=" http://open-services.net/ns/core#Version"/> to know if a resource instance is asserted to be a Version or not. If a Version, client expects to find >=1 dcterms:isVersionOf triple; if not (presumably - would need your feedback here) such a client would assume a resource instance is a Base, and inspect it for the optional dcterms:hasVersion triple(s). Such a client would have the option of limiting itself to that "view of the world" or it could also choose to provide additional behavior based on other content it finds (like rdf:type values). That seems pretty generic, so the client code would be able to process a wide breadth of resource types w/o being sensitive to each most derived type. Clients unaware of Versions simply ignore the content like any other they don't understand. If we end up accepting the "ResourceVersion" types approach, I think you'd have to add a constraint too that "ResourceVersion" types must have identical required properties as the "Resource" type prior to "adding on" the ...Version resource definition's required properties. Comment 2: When you say "resource of same type" in your resource definition, what do you mean in RDF terms by that, remembering that an RDF resource has multiple types? Comment 3: > It shall support a createVersion service How would a client distinguish between the base resource's "legacy" creation factory and this new one, given that oslc:Service only allows the oslc:domain URI as a way to distinguish them? It appears that you'd need each spec to define a URI for its createVersion service when it wants to support versioning. A single creation factory may accept many different input representations on create, including those with different types, so it's not obvious to me why you want to require a separate factory ... if the need is accepted, then I don't see how you avoid the need for another URI in each "version supporting" spec (and is it 1 URI/spec, or 1/resource definiton?). Comment 4: When you say rdf:type occurs zero-or-many in your resource definition, I think you want one-or-many given your requirement that >=1 be the type URI for ResourceVersion. [1] http://open-services.net/bin/view/Main/CoreExtensionForPlm?sortcol=table;up=#Appendix_A_Samples [2] http://open-services.net/pub/Main/CoreExtensionForPlm/AM_versioned_resource_examples_AMG60104_004-POWERSUBSYSTEM.xml Best Regards, John Voice US 845-435-9470 BluePages Tivoli OSLC Lead - Show me the Scenario From: Gray Bachelor <[email protected]> To: [email protected], [email protected] Date: 11/10/2011 09:15 PM Subject: [oslc-core] Updated Core extension proposal for versioning Sent by: [email protected] Dear OSLC PLM and Core workgroup members Following the Oct 5th meeting and postponed Core Nov 2nd please find update Core proposal for versioning support with examples Some of the feedback has been included http://open-services.net/bin/view/Main/CoreExtensionForPlm I cant make the Core WG 16th so I look forward to your feedback Suggestions are welcomes to build up the wiki page Best regards Gray Solution Architect Systems and Industrial solutions, Rational HQ Devt org, IBM SWG Tel: (44)(0)1926-464345 Alternative Tel: (44)(0)2476 713 274 Mobile Tel: (44)(0)784 10 11 431 E-mail [email protected] Unless stated otherwise above: IBM United Kingdom Limited - Registered in England and Wales with number 741598. Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire PO6 3AU _______________________________________________ Oslc-Core mailing list [email protected] http://open-services.net/mailman/listinfo/oslc-core_open-services.net
