Agenda

1. Quickly summarize points from last meeting.
2. Continue review discussion of draft specification.
   1. Discuss the semantics of PUT/POST of link and resources in presence of read-only, and modifiable properties.
   2. Solicit a volunteer to own the query spec and discuss approach.

Minutes

Atendees: Andy Berner, Ian Hancock, Ian Green, Jim Amsden, Jonathan Harclerode, Vishy Ramaswamy

1. Summary of the previous meeting. Most notably we decided to not attempt to include support for removing back links, nor manke any assumption on how other services manage their links.
2. Jim C. started the discussion with a comment make by Ian G. regarding the semantics of PUT and POST of resource properties that are read only. Is the client responsible for passing on these properties during a PUT, or can it drop them. Also is the client responsible for passing on all properties (elements) that it receives back to the server during a PUT even if it doesn't understand them. This has implications for future backward compatibility.
3. Andy suggested that this should e an OSLC wide concern, and we all agreed. However Jim C mentioned that we still need to address it here, and we will them take our position to the OSLC Leads group, which will consider it for adoption across the whole OSLC in the 2.0 spec timeframe.
4. Ian G. said he would contact Steve Speicher of the OSLC CM workgroup, to ask why they didn't address it in the CM 1.0 spec.
5. The discussion continued with two significant approaches surfacing. First we could find the wording for the spec to basically require all clients POSTing or PUTing resource to be required to include all properties (XML elements and attributes). Missing properties would be considered a delete of that property. This also places a responsibility on the client to hang on to, and pass back all properties that it does not understand. In this case it is required that the client return all XML elements that it receives and does not understand in exactly the same order that it was retrieved.
6. The other approach was proposed by Jim A. who suggested that the interface expose an underlying RDF store, in which case clients need only POST/PUT the triples that they know about, and delete the ones they know about. Clients can get the triples and use reflection on them to discern what it wants to know, and put them back.
7. Other suggestions for managing deletes that involved creating virtual command stacks. Some interesting scenarios were presented, but by the end the consensus was that for the 1.0 time frame we would include some wording into the spec that is along the lines of the first suggestion.
8. Jim C. mentioned that Jim A. kindly provided RDF Schema representations of the resource formats. He also asked the group if it would make sense to include in the API a means for clients to request the schemas so they could process them.
9. Vishy said that other tools did this, and supported the idea.
10. Ian G. posed that it would be nice to generate our resource format documentation directly from these RDF schemas, but currently no one had the right tooling to do so.
11. Vishy asked for confirmation that this spec was not going to address versions of resources. Ian G. added that the OSLC RM workgroup also decided to push out versioning in their specification.
12. Vishy then asked how internal links created by the AM tools (i.e. UML modeling tool), that link one AM resource to another managed by the same tool, were being treated.
13. Jim C. suggested that for this specification, the server implementation would decide if internal links were exposed to clients in the same way that the ALM links, created via this specification. But we should state that it is required for all links created with this interface, be vivible through the interface.
14. Jim C. said that this didn't prevent a resource knowledgable client from requesting the raw resource and parsing it to find internal links. Just that the only links garanteed to appear in the links collection returned by this interface will be those created by the interface. If a server implementation wanted to convert or surface internal links as well, it was up to that specific implementation.
15. Jim C. asked the group for a volunteer to own the query spec part of this specification. Ian G. pointed out that the OSLC RM team decided not to include query as part of their spec because none of the use cases required it. In our case if we wanted to support true impact analysis we'd need some minimal query support that included links, so that queries could be run that found elements without relationships as an example.
16. Vishy volunteered to draft that part, and Ian G agreed to help. Summary of the previous meeting. Most notably we decided to not attempt to include support for removing back links, nor manke any assumption on how other services manage their links.
17. Jim C. started the discussion with a comment make by Ian G. regarding the semantics of PUT and POST of resource properties that are read only. Is the client responsible for passing on these properties during a PUT, or can it drop them. Also is the client responsible for passing on all properties (elements) that it receives back to the server during a PUT even if it doesn't understand them. This has implications for future backward compatibility.
18. Andy suggested that this should e an OSLC wide concern, and we all agreed. However Jim C. mentioned that we still need to address it here, and we will them take our position to the OSLC Leads group, which will consider it for adoption across the whole OSLC in the 2.0 spec timeframe.
19. Ian G. said he would contact Steve Speicher of the OSLC CM workgroup, to ask why they didn't address it in the CM 1.0 spec.
20. The discussion continued with two significant approaches surfacing. First we could find the wording for the spec to basically require all clients POSTing or PUTing resource to be required to include all properties (XML elements and attributes). Missing properties would be considered a delete of that property. This also places a responsibility on the client to hang on to, and pass back all properties that it does not understand. In this case it is required that the client return all XML elements that it receives and does not understand in exactly the same order that it was retrieved.
21. The other approach was proposed by Jim A. who suggested that the interface expose an underlying RDF store, in which case clients need only POST/PUT the triples that they know about, and delete the ones they know about. Clients can get the triples and use reflection on them to discern what it wants to know, and put them back.
22. Other suggestions for managing deletes that involved creating virtual command stacks. Some interesting scenarios were presented, but by the end the consensus was that for the 1.0 time frame we would include some wording into the spec that is along the lines of the first suggestion.
23. Jonathan confirmed that at least for the AM Resource format, there was sufficient information to make it useful for impact analysis, and said that even just knowing the existance of a resource is 50% of the way there, and anything else [like typed links] was just iceing.
24. Jim C. mentioned that Jim A. kindly provided RDF Schema representations of the resource formats. He also asked the group if it would make sense to include in the API a means for clients to request the schemas so they could process them.
25. Vishy said that other tools did this, and supported the idea.
26. Ian G. posed that it would be nice to generate our resource format documentation directly from these RDF schemas, but currently no one had the right tooling to do so.
27. Vishy asked for confirmation that this spec was not going to address versions of resources. Ian G. added that the OSLC RM workgroup also decided to push out versioning in their specification.
28. Vishy then asked how internal links created by the AM tools (i.e. UML modeling tool), that link one AM resource to another managed by the same tool, were being treated.
29. Jim C. suggested that for this specification, the server implementation would decide if internal links were exposed to clients in the same way that the ALM links, created via this specification. But we should state that it is required for all links created with this interface, be vivible through the interface.
30. Jim C. said that this didn't prevent a resource knowledgable client from requesting the raw resource and parsing it to find internal links. Just that the only links garanteed to appear in the links collection returned by this interface will be those created by the interface. If a server implementation wanted to convert or surface internal links as well, it was up to that specific implementation.
31. Jim C. asked the group for a volunteer to own the query spec part of this specification. Ian G. pointed out that the OSLC RM team decided not to include query as part of their spec because none of the use cases required it. In our case if we wanted to support true impact analysis we'd need some minimal query support that included links, so that queries could be run that found elements without relationships as an example.
32. Vishy volunteered to draft that part, and Ian G agreed to help.