index / Automation Meetings / This page
Time: 11:00AM Eastern US (Currently 3pm UTC, 5pm CET)
Actions from previous meetings
Steve Speicher, John Arwe, Ian Green, Tim Fressinger, Martin Pain
- Approved minutes of meeting on 2014-07-17
- Apply some selection of Ian’s suggestions to the Actions 2.0 specification:
- Ian.I.4: Change the requirement for text/turtle to application/rdf+xml.
- Ian.I.5: Change to require that each oslc:binding of type http:Request specifies a single http:Request rather than a ‘class’ of such requests.
- 2014-09-11: Note that this was amended in the Aug 21 meeting: the “don’t cherry pick” discussion we had last time (Aug 14) was not limited to http:Requests, it’s all the bindings’ subsidiary requests as well.
- 2014-09-12: Changes live, email out requesting careful review
- Ian.II.1: Provider “serves” resources, not “creates” resources.
- Ian.II.2.1: Remove “potentially consumable”.
- Ian.II.2.2: Use wording “For each interaction pattern that is supported by the consumer (that is, the interaction patterns supported by the consumer, along with the restrictions, if any, defined by the profile(s) they were implemented against)”.
- Ian.II.2.3: Correct typo.
- Ian.II.3.3: Use words to the effect of “available at time response was created” rather than “currently available”.
Meetings from last meeting approved (july 17th), no objections
Topic: Workgroup end-of-life and transition plan
no objections with plan outlined
Topic:Action metadata not covered, waiting for Anamitra
Topic: Actions 2.0 review commends by Ian
Numbering sections - wiki doesn’t support it, respec tool does
agreement to wait until OASIS move and let respec take care of it
app/xml - is a Core 2.0 requirement
…once moved to OASIS, say Actions 3.0, the requirement would be text/turtle since based on LDP
Martin: question on what Anamitra’s needs and using app/xml
JohnA: they depend on OSLC-JSON and perhaps get app/xml “for free” based on framework built on, would need to check
Martin: Do we record these all Ian’s points separately on the issues page?
Ian: thinking it would just be tracked like this meeting, then move into a “real” issue
SteveS: suggests what Ian said, perhaps put 1 issue for Ian’s comments and separate any that require ongoing work/discussion
We agreed with Ian’s suggestion to “to require that each oslc:binding of type http:Request speci?es
a single http:Request rather than a ?class? of such requests”
Next: Ian.II.1: Provider “is authority of” not “creates” resources.
John: thinks authority may not be right either, serves perhaps is better
Martin: Proposal to use ‘serves
SteveS: +1 for serves
JohnA: fine with ‘serves’, not sure needs to be anything different in 3.0
Next: Ian.II.2.1: What does “potentially consumable” mean?…
JohnA: ok with responses?
Ian: fine with it
Next: Ian.II.2.2: Rephrase: “For each interaction pattern that is….
Martin: (see email proposal)
Ian: no problem with it
Next: 2.3, typo
Next: 3.3: How we clarify ..
Ian: thought Martin’s explanation was good, helped him understand
…instead of current time, perhaps instead when the response is issued
Martin: to change to something like “available at time response was created” instead of “current time”
Next: additional Ian’s comments that we don’t address…
Martin: suggest we take to mailing list (reviews items)
Martin: no further update from Tim as next we move to OASIS
JohnA: question on “mutual dependency” and ok with it
Ian: concern over circular dependency, felt some of the references were in wrong direction, but not something needed to be repaired
Martin: suggest leave as-is and revisit in future version
(scribe needs to leave)
Topic: Bi-driectional dependency?
1 - If we make it clear that these patterns are optional then it’s clearer that their consequences are optional
2 - or, we move that pattern to automation & link it
We’ll bring this topic up again next week.
Next meeting: next week