History   View   Links to this page 2014 September 12 | 01:50 pm

index / Automation Meetings / This page

Time: 11:00AM Eastern US (Currently 3pm UTC, 5pm CET)

Agenda

Chair: Martin

  • Issues - see mailing list

  • Main agenda items:

    • Review 17 July minutes
    • Workgroup end-of-life/transition plan
      • Receiving reviews, then finalization, for Automation 2.1 & Actions. Then in maintenance mode for 2.1.
      • Finishing Availability spec.
        • Intending to move this to OASIS. - Tim & Juergen.
    • Automation 2.1 & Actions
      • Action metadata at resource type/shape level (Scroll down for initial email). - Scenario submission from Anamitra?
      • Actions 2.0 Review by Ian
        • Responses by Martin: Part I - General comments/questions, Part II (1-3) : Typos, clarifications
        • Do we record these all Ian’s points separately on the issues page?
        • Ian.I.1: Numbered sections.
        • Ian.I.4: Application/rdf+xml support.
        • Ian.I.5: Would it be simpler not to allow options in http:Request resources, but to require multiple resources for all the possibilities? (Currently up to the number of HTTP interaction patterns multiplied by the number of HTTP versions supported.)
        • Ian.II.1: Provider “is authority of” not “creates” resources.
        • Ian.II.2.1: What does “potentially consumable” mean? Martin proposes we remove that phase. 2 other suggestions in email.
        • Ian.II.2.2: Rephrase: “For each interaction pattern that is supported by the consumer (that is, the interaction patterns supported by the consumer, along with any restrictions, if any, defined by the profile(s) they were implemented against):”
        • Ian.II.2.3: Typo
        • Ian.II.3.3: How do we clarify the intention around domain specs’ use of predicates pointing to actions? [Long] suggestion in email Aug 6th.
        • Issues Martin proposes we don’t address (as it would generate too much work or wouldn’t bring enough benefit): Ian.I.2 (other provider’s resources - no scenario), Ian.I.3 (appearance of mutual dependence), Ian.II.3.1 (“Description” section name), Ian.II.3.2 (WGs MUST talk to Core), Ian.II.3.4 (“hash URIs”). Any objections? Anyone want to +1 any of these points?
    • “Availability”
    • Workgroup business
      • Next meeting?
    • AOB

Actions from previous meetings

None

Minutes

Attendance

Steve Speicher, John Arwe, Ian Green, Tim Fressinger, Martin Pain

Resolutions passed

  • 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.
      • 2014-09-11: Changes live
    • 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.
      • 2014-09-11: Changes live
    • Ian.II.2.1: Remove “potentially consumable”.
      • 2014-09-11: Changes live
    • 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)”.
      • 2014-09-11: Changes live
    • Ian.II.2.3: Correct typo.
      • 2014-09-11: Changes live
    • Ian.II.3.3: Use words to the effect of “available at time response was created” rather than “currently available”.
      • 2014-09-11: Changes live

Minutes

Scribe: SteveS

Meetings from last meeting approved (july 17th), no objections

Topic: Workgroup end-of-life and transition plan

no objections with plan outlined

See http://open-services.net/wiki/automation/AutomationMeetings20140814/

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)

Topic: Availability

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?

Martin: Options:

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

Meeting adjourned