[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Jan 2013 F2F: three day raw chatroom notes
Adrian Otto (Rackspace): \
Adrian Otto (Rackspace): The Voice Conference code is: 3005864
Adrian Otto (Rackspace): The US Access number is 1 866-682-4770
Tobias Kunze (Red Hat): Good morning everyone
MartinC - webex: Meeting Number: 598 770 660 Meeting Password: 2267
https://oracleconferencing.webex.com/oracleconferencing/j.php?J=598770660&PW=NZDFmYzZlMDI2
jeffm: are u taking attendance yet?
Please change your name from 'anonymous' using the Settings button
Adrian Otto (Rackspace) (scribe): Meeting Commenced
Adrian Otto (Rackspace) (scribe): Roll Call
Adrian Otto (Rackspace) (scribe): 70% attendance: Meeting is quorate.
Adrian Otto (Rackspace) (scribe): Review of day 1 agenda
Adrian Otto (Rackspace) (scribe): Anish raises issue of target launch date for our v1.1 effort. Oasis Standard is one milestone we can
aim for. We want to be at that point within 1 year, and we are a few months in. Suggests working back from a target date.
Adrian Otto (Rackspace) (scribe): We plan to address this subject during the part of our meeting when we discuss the relative priority
of the open issues.
Adrian Otto (Rackspace) (scribe): High priority issues should have target dates assigned so we can plan progress in order to meet the
milestone.
Adrian Otto (Rackspace) (scribe): No objections to modified agenda.
Adrian Otto (Rackspace) (scribe): Agenda approved.
Adrian Otto (Rackspace) (scribe): Agenda was not modified from the version in email.
Adrian Otto (Rackspace) (scribe): correction: Agenda has a modification.
Martin will update, and copy/paste it here in the chat.
Duncan Johnston-Watt: Long term workplan discussion to be added to agenda
MartinC : Submitter's message
Draft Agenda ....
-- Dr. Martin Chapman
Event Title: 2nd CAMP F2F
Agenda
Times are US Central Time
Wednesday 21st January
09:00
Intro, Roll, Scribes
Agenda bashing
Minutes 16th January 2013:
https://www.oasis-open.org/apps/org/workgroup/camp/email/archives/201301/msg00040.html
Administrivia
Editing Team update
New issues
10:30
Break
11:00
General extensibility discussion kicked off by Gil:
https://www.oasis-
open.org/apps/org/workgroup/camp/email/archives/201301/msg00044.html
See email thread
12:30
Lunch
13:30
Specific extensibility issues:
https://tools.oasis-open.org/issues/browse/CAMP-1 Need a way
to get metadata for a particular resource
https://tools.oasis-open.org/issues/browse/CAMP-10 API+Model
Extensions
https://tools.oasis-open.org/issues/browse/CAMP-14 How are
supported formats discovered
15:00
Break
15:30
https://tools.oasis-open.org/issues/browse/CAMP-38
resourceState attribute needs clarification
Other lifecycle issues?
17:30
Thursday 22nd January
09:00
Test Assertions Discussion - Jacques to lead
10:30
Break
11:00
Liaison - presentation on OCCI (time to be confirmed)
Note that since OASIS doesn't allow non members to make contributions, and material and discussion must be restricted to publicly
available information only.
12:30
Lunch
13:30
TC timeline and planning
15:00
Break
15:30
Open Issue Prioritization - exercise to categorize into P1 (must fix), P2 (should fix), P3 (nice to fix)
17:30
Friday 23rd January
09:00
Issues discussion in priority order.
10:30
Break
11:00
Work plan, wrap up
12:30
END
Adrian Otto (Rackspace) (scribe): Gilbert Pilz motions to approve the minutes from Jan 16, 2013
Adrian Otto (Rackspace) (scribe): Second by Tom Rutt
Adrian Otto (Rackspace) (scribe): Martin asks if the text based minutes format is acceptable by the members.
Adrian Otto (Rackspace) (scribe): the format is indicated to be fine.
Adrian Otto (Rackspace) (scribe): no discussion on minutes
Adrian Otto (Rackspace) (scribe): no objections
Adrian Otto (Rackspace) (scribe): minutes from Jan 16, 2013 are approved.
Adrian Otto (Rackspace) (scribe): No administrivia to discuss.
Adrian Otto (Rackspace) (scribe): Editors produces a CSD package, a zip file containing Word, PDF, and HTML formats. The CSD
publication process by the TC Admin is now underway.
Adrian Otto (Rackspace) (scribe): WD02 will be used for any modifications from this point.
Adrian Otto (Rackspace) (scribe):
https://www.oasis-open.org/committees/download.php/47987/camp-spec-v1.1-wd02.zip
Adrian Otto (Rackspace) (scribe): Jacques requests that TC members review the draft of the test assertions document prior to
discussion tomorrow. It is a 14 page document.
Adrian Otto (Rackspace) (scribe): Discussion of new issues:
https://tools.oasis-open.org/issues/browse/CAMP-14
Adrian Otto (Rackspace) (scribe): Gilbert Pilz: Motion to open issue CAMP-14
Adrian Otto (Rackspace) (scribe): Adrian Otto seconds motion
Adrian Otto (Rackspace) (scribe): no objections
Adrian Otto (Rackspace) (scribe): issue carried, CAMP-14 is open.
Adrian Otto (Rackspace) (scribe): Action Item for Martin C: Check that all associated issues are appropriately allocated to the spec.
Adrian Otto (Rackspace) (scribe): Correction: New issue CAMP-39 is opened, not CAMP-14
Adrian Otto (Rackspace) (scribe): Discussion of new issue:
https://tools.oasis-open.org/issues/browse/CAMP-40
MartinC lowered your hand
Adrian Otto (Rackspace) (scribe): Tobias Kunze speaks in support of the issue
Adrian Otto (Rackspace) (scribe): Anish K speaks in support of the issue
Adrian Otto (Rackspace) (scribe): Jacques suggests that another related issue exists. Resources created under one API version may
need to be accessible from other API versions. Tom Rutt asks if CAMP-40 is concerned with this scope of the issue. Gilbert Pilz
confirms that Jacques' issue is beyond the scope of CAMP-40.
Adrian Otto (Rackspace) (scribe): Gilbert Pilz motions to open CAMP-40
Adrian Otto (Rackspace) (scribe): Motion seconded by Duncan Johnston-Watt
Adrian Otto (Rackspace) (scribe): No discussion
Adrian Otto (Rackspace) (scribe): No objections
Adrian Otto (Rackspace) (scribe): CAMP-40 is now open.
Adrian Otto (Rackspace) (scribe): Break time. Resume in 20 minutes
(10:35 US/Central)
Adrian Otto (Rackspace) (scribe): Break time concluded.
MartinC : Topic: General extensibility discussion kicked off by Gil:
Adrian Otto (Rackspace) (scribe): Gil begins a discussion on Extensibility
MartinC :
https://www.oasis-open.org/apps/org/workgroup/camp/email/archives/201301/msg00044.html
Adrian Otto (Rackspace) (scribe): Anish suggests that the spec outline rules/boundaries that extensions must follow in order to remain
compliant.
MartinC lowered your hand
Mark Carlson (Oracle): As I said in the email thread. We need a conformance statement that disallows "incompatible" extensions,
along with the spec text that normatively illustrates *how* to extend CAMP compatibly.
anish: +1
anish: all oasis spec requires a 'conformance' section -- this should go there
MartinC : extensions must not contradict the specification.
Charlie Tupitza JumpSoft: Please speak towards the Microphone. it is
very hard to hear words..
Duncan Johnston-Watt: It is not an extension if it breaks the core spec
- conformance should capture this obviously - but there is a separate issue which is whether extensions collide with one another ...
not sure we can solve this in general case?
Adrian Otto (Rackspace) (scribe): Consensus reached that Extensions must not contradict the spec.
Adrian Otto (Rackspace) (scribe): Considerable support for the idea that mandatory Extensions should not be allowed. Active
discussion of this point.
Duncan Johnston-Watt: +1
Adrian Otto (Rackspace) (scribe): Jacques suggests that extensions should be allowed, provided they to not fail the base set of test
assertions.
Adrian Otto (Rackspace) (scribe): s/to/do/
Duncan Johnston-Watt: +1 - that is one aspect of conformance
(compliance?) with spec
MartinC lowered your hand
Adrian Otto (Rackspace) (scribe): Anish suggests that extensions mandated by a service provider will be required. The absence of this
requirement will be impossible because not enough is included in CAMP to make a useful PaaS service work.
Adrian Otto (Rackspace) (scribe): Discussion of Extensions that would be common among multiple implementations. Gil indicates we
should not call that a Standard Extension.
Jacques (Fujitsu): There is a "business" contract, where a Provider may require mandatory extensions to be used. But that is out of
scope of CAMP spec. These could be concretized as "CAMP profiles" (e.g. Java platforms). As far as conformance is concerned, there
should be a core way to conform (core test suite) that is not violated by any extension (no test regression)
Tom Rutt (Fujitsu): We need to distinguish two concepts: Vendor extensions within the scope of the standard API, vs. mandatory
extensions to the Standard API. The second concept is the one which
causes feasability problems for testing the standard API
Mark Carlson (Oracle): We might learn from the way the SNIA is extending
CDMI.http://www.snia.org/tech_activities/publicreview/cdmi lists several extensions that are not made "standard" until multiple
implementations are demonstrated. Then and only then they are moved into a future version of the standard.
anish: we also have to be mindful of what our charter says wrt 'out of
scope':
anish: "Facilities and interfaces that are programming language-specific and/or platform-specific (e.g. .Net, Java EE). "
Adrian Otto (Rackspace) (scribe): Gil suggests some terminology to refer to a grouping of related extensions. We should refer to this as
a Feature.
MartinC lowered your hand
Adrian Otto (Rackspace) (scribe): Break for lunch. Resume in 1 hour.
1:15 PM US/Central
Alex Heneveld (Cloudsoft): I have posted some vocab for "extension types" as a comment at https://tools.oasis-
open.org/issues/browse/CAMP-10
Scribe: ping
Scribe: Meeting resumes after a lunch
TheScribe: Specific extensibility issues:
TheScribe: https://tools.oasis-open.org/issues/browse/CAMP-1 Need a
way to get metadata for a particular resource
jeffm: that was me dialing in
TheScribe: concrete proposal:
https://www.oasis-open.org/apps/org/workgroup/camp/download.php/47367
TheScribe: Anish> (presents concrete proposal)
Tobias Kunze (Red Hat): How about we simply name this "metadata=yes"?
Tobias Kunze (Red Hat): I agree with Alex, "_PaaSRT" feels "ugly"
TheScribe: Anish> this proposal needs work - it is a hold-over from the collaboration days
TheScribe: Adrian> the lists of attributes is not identified by types
TheScribe: Anish> you can't use an extension unless you know its semantics - since you have to look those up in any case, don't see
the point of listing types, etc.
TheScribe: ... could add a URL that tells you where to get the documentation
TheScribe: Alex> issue description discusses "resources" and "resource types"
TheScribe: ... need a way to navigate the types that are exposed in the system
TheScribe: ... maybe that should be a top-level resource e.g. "apiDocs"
TheScribe: ... also a need a way to get the per-instance list of all the attributes that have values
TheScribe: ... or cases where instances have more attributes than their type
TheScribe: Gil> why are you telling me about attributes and types that are defined in the spec - I know they exist
TheScribe: Anish> makes it easier to process these lists in a mechanical way if you don't have to special case the types and attributes
that are defined in the spec
TheScribe: Gil> also uncomfortable with the idea of instances that contain attributes that are not defined by their type
TheScribe: ... don't see the point of defining such a thing as a "resource type" if we don't play by the rules of what we have defined
that concept to mean
TheScribe: Jacques> are the underscores around the _PaaSRT_ query parameter, a CAMP convention?
TheScribe: Anish> don't want to conflict with other query parameters, but name is the least important thing
TheScribe: Jacques> if it is "nice" to get the names of all the spec-defined attributes, it is similarly "nice" to get type information on the
attributes
TheScribe: Tom> is there some way to get "all" the metadata in one shot?
TheScribe: Anish> you have to think about how you are going to retrieve and use the metadata
TheScribe: Anish> w/regards to an "apiDocs" resource, I'd like to see more detail on how you would use this to get a list of types or a
list of the attributes supported by a type
TheScribe: Adrian> (goes to the glass)
TheScribe: Anish> you need the ability to discover the list of the supported attributes for a type before any instances of that type exist
TheScribe: ... w/regards to instance attributes beyond those of the attributes for a type, CAMP defines a resource-model - not clear
how useful this is if we don't conform to the types we define
TheScribe: (goes to the glass)
TheScribe: Anish> we have a decision to make: query paramater or URL patterns?
TheScribe: Martin> could support two different queries - one that gives you back a list of "everything" and another that gives you back
just a list of the stuff that's not defined in the spec
TheScribe: ... begs the question of namespacing - separating one extension from another
TheScribe: Alex> seems like we have a lot of big, open questions
TheScribe: ... need to bottom-out this 'type' discussion
TheScribe: ... defining a new type every time I want to do something like add monitoring attributes is onerous
TheScribe: Mark> whatever scheme we come up with, I'd like it to deal with specializing Platform Components
TheScribe: ... need to figure out how to do "specialization by sub-classing"
MartinC : we could use Avro IDL http://avro.apache.org/docs/current/idl.html
TheScribe: (general discussion)
MartinC : (if one was a pervert)
TheScribe: Adrian> (goes to the glass)
TheScribe: Adrian> we don't need to define fixed URI stems (e.g.
".../api/versions"), just need to define attributes in Platform that give your the URL of the thing you are looking for
TheScribe: ... e.g. "versionURI" : "http://whatever/whatever/versions";,
"typesURI" : "http://whatever/whatever/types";, ...
TheScribe: Anish> below "types" you can define a URI pattern that says "assembly" will get you the metadata for the Assembly
resource type
TheScribe: ... I'm beginning to prefer this over query parameters
TheScribe: ... is there anybody who thinks this is a bad idea
jeffm: sounds like a good idea
Alex Heneveld (Cloudsoft): straw poll request: do people prefer (A) Theoretical REST where you don't know any URL's except the
main endpoint, and you traverse well-known-labelled links; or (B) Practical RESTful API style where the URL format is defined e.g.
/resource/R1/xxx/; ... or (C) both
jeffm: actually, i think as long as there is a well defined way to get the metadata, it probably doesn't matter that much how its done
MartinC lowered your hand
TheScribe: Anish> spec should do A, implementations can do B (thus making them C)
TheScribe: Anish> we don't have any type hierarchy (resource types and
sub-types) in the spec right now
TheScribe: Jeff> don't think it matters that much whether you chose A or B (C would be awful), as long as there is a well-defined way
to get the information
TheScribe: ... don't worry about REST purity, developers don't care
TheScribe: ... doing both is the worst of all possible worlds
TheScribe: ... except for "either or"
TheScribe: Alex> I'm going to take away my objection to 'B' - 'A' is beneficial to the provider (can spread things out) but it is harder for
the developer (e.g. curl | grep | curl | grep) so 'B' is more developer friendly
TheScribe: Anish> like 'A' more and more (turtles all the way down) - provider can recurse as far they feel is beneficial
TheScribe: ... with 'B' you can only recurse as far as CAMP defines a pattern
MartinC lowered your hand
TheScribe: Jeff> what is the difference between traversing well-kown links and pre-defined URI patterns
TheScribe: Alex> 'A' makes it easier to federate
TheScribe: Alex> 'A' is more flexible that 'B' - 'A' can be used to subsume an implementation that previously used 'B' without breaking
any clients that depend on the URI patterns
Alex Heneveld (Cloudsoft): BTW I have opened
https://tools.oasis-open.org/issues/browse/CAMP-44 to clarify our use of types
TheScribe: awesome
TheScribe: https://tools.oasis-open.org/issues/browse/CAMP-10
API+Model Extensions
TheScribe: Adrian> (refresh of the issue)
MartinC :
http://www.mnot.net/blog/2011/10/12/thinking_about_namespaces_in_json
TheScribe: Adrian> need to enable de-centralized development CAMP extensions
Tobias Kunze (Red Hat): Suggestion: add a reserved "extensions" key to EVERY resource whose value is a dictionary where every
vendor can use their name to add their extension
TheScribe: ... proability of two people picking the same prefix is remote but the probability of two people picking "serverID" as an
attribute name is fairly high
Tobias Kunze (Red Hat): example: { ..., "extensions": { "com.redhat": {
"mykey": "myval", ...}}}
TheScribe: Adrian> that's conistent with my suggestion
TheScribe: ... this works for extensions, but it doesn't work for attributes
anish: javascript variable name validator: http://mothereff.in/js-variables
TheScribe: Martin> don't see much difference between this and flat names like "com.redhat.mykey"
Tobias Kunze (Red Hat): the difference is that "com.redhat.key1", ..., "com.redhat.key-n" could be potentially large and hard to read
Tobias Kunze (Red Hat): the difference is that "com.redhat.key1", ..., "com.redhat.key-n" could be potentially large and hard to read
TheScribe: Alex> seems to be sympathy for the use of domain names - despite the syntactic headaches they may cause for dynamic
languages
TheScribe: Adrian> recommend stock ticker symbol (if you have one) otherwise use your domain name
Alex Heneveld (Cloudsoft): Suggestion: Extension attributes on well known types SHOULD be prefixed by a domain name. Custom
types SHOULD be prefixed by a domain name. Standard attributes on a custom type SHOULD NOT be prefixed by a domain name.
TheScribe: Gil> can we separate the issues? (1) separator characters (2) name basis
TheScribe: Alex> underbars
TheScribe: e.g. "com_redhat"
Jacques (Fujitsu): testability: as long as a normative spec req can be tested just by (a) a hard-coded condition on message content, or
(b) a consistency condition between message(s) content (say a metadata query followed by an instance query), then we'r OK testwise.
What we don't want is to have to go read an external doc or resource to figure whether a message is correct.
TheScribe: DIRECTIONAL RESOLUTION: "com_redhat_foo" (not "com.redhat:foo", really not "com.redhat.foo", really, really not
"com.redhat_foo")
MartinC lowered your hand
Jacques (Fujitsu): OpenStack extensions:
Jacques (Fujitsu): New elements and attributes. Extensions may add additional data elements or attributes to existing MIME types.
New resources. Extensions may define entirely new API resources.
New parameters. Extensions may introduce new query parameters to existing resources.
New headers. Extensions may define new HTTP headers.
New verbs. Extensions may introduce support for an HTTP verb (PUT,
POST) to an
existing core resource.
New media types. Extensions may define entirely new representation types for existing resources.
New actions. Extensions may define new actions on existing resources.
New states. Extensions may introduce new states in an API state machine.
Other capabilities. Extensions may define other general API capabilities. For example, the ability to edit an otherwise uneditable
attribute.
Tom Rutt (Fujitsu): for coffee lovers check out http://summitcountyvoice.com/2012/11/09/global-warming-puts-wild-arabica-
coffee-plants-at-risk/
Jacques (Fujitsu): issue #14
MartinC : https://tools.oasis-open.org/issues/browse/CAMP-14
Jacques (Fujitsu): issue #14
MartinC : https://tools.oasis-open.org/issues/browse/CAMP-14
TheScribe: Back from break
TheScribe: https://tools.oasis-open.org/issues/browse/CAMP-14 How are
supported formats discovered
TheScribe: DIRECTIONAL RESOLUTION: If a provider claims to provide a particular format, *every* resource available through the
tree rooted in "Platform" MUST be available in that format
TheScribe: Gil> strawman (similar to proposals for versions and types) add a "formatsURI" to Platform that references a catalog
resource of format names (e.g. "JSON", "XML") and links to descriptions of those formats
TheScribe: Adrian> list JSON
TheScribe: https://tools.oasis-open.org/issues/browse/CAMP-38
resourceState attribute needs clarification
TheScribe:
https://www.oasis-open.org/apps/org/workgroup/camp/download.php/47943/camp-38-2013-01-18.doc
Jacques (Fujitsu): "READY" for what? (isn't "CREATED" good enough?)
MartinC : sysnonyms Jacques
MartinC lowered your hand
Jacques (Fujitsu): if we need to know the details of resource-level ops, tasks or jobs are better, less ambiguous.
Mark Carlson (Oracle): Creating, Ready, Busy, Error, and Destroying are a great example of an underlying resource state machine that I
mentioned. For ResourceReady it would be either the YES or NO values.
MartinC : cloud job control language!
Mark Carlson (Oracle): There are some resources that are always there (like Platform) - they have no other state attribute - they are
Always ResourceReady=true. Cannot create, cannot delete, and should never be in any error state....
Jacques (Fujitsu): in favor of CAMP defining a basic binary status at resource level: OK / not OK (to use). Anything more will call for
terminology trouble... (and if a Provider wants to give more info, a "jobs status" capability can be optionally added)
Jacques (Fujitsu): or a log capability.
Mark Carlson (Oracle): I think maybe we should defer this issue until we have a worked example.
Alex Heneveld (Cloudsoft): controlStatus: CREATING, READY, ERROR, DESTROYING
MartinC : meeting recessed
Adrian Otto (Rackspace): Voice Bridge: 866-682-4770 Code: 3005864
Passcode: CAMP
Charlie Tupitza JumpSoft: present
Duncan Johnston-Watt (Scribe): OCCI presentation to be moved to 10.00 Friday
Duncan Johnston-Watt (Scribe): Day 2 - Test Assertions Discussion
Michael Behrens: Calling in now.
Duncan Johnston-Watt (Scribe): Camp 38 (Gil) and Camp 10 (Adrian) proposals to be discussed after the break at 11.00
Duncan Johnston-Watt (Scribe): Draft proposals for Camp 9 & 42 (Alex) to be added to discussion after break at 11.00
Duncan Johnston-Watt (Scribe): Martin to post links to PPT and draft into chat room
Duncan Johnston-Watt (Scribe): Jacques > Recap on purpose of testing
(https://wiki.oasis-open.org/tab/TestingPolicy) -
Duncan Johnston-Watt (Scribe): 1. Validating a specification
Duncan Johnston-Watt (Scribe): 2. Verifying an implementation
MartinC : Jacques presentation from November:
https://www.oasis-open.org/apps/org/workgroup/camp/download.php/47418/CAMP-Testing.ppt
MartinC : camp-ta editors draft outline:
https://www.oasis-open.org/apps/org/workgroup/camp/download.php/47838/camp-ta-v1.1-wd01b-candidate.doc
Duncan Johnston-Watt (Scribe): Ref 1: Developing test suite alongside development of spec helps tease out
gaps/inconsistencies/ambiguity
Duncan Johnston-Watt (Scribe): Ref 2: Three aspects conformance with spec; interoperability with other implementations;
maintenance
Duncan Johnston-Watt (Scribe): Adrian > Will we have test tools? Or just documentation?
Duncan Johnston-Watt (Scribe): Anish > Undecided.
Duncan Johnston-Watt (Scribe): MartinC > Table issue for planning session.
Duncan Johnston-Watt (Scribe): Anish > Would like test suite to be a "product" of TC
Duncan Johnston-Watt (Scribe): Developing test suite might impact timeline for TC
Duncan Johnston-Watt (Scribe): Jacques > It can be an important contribution to certification program
Duncan Johnston-Watt (Scribe): Roshan > Conformance does not guarantee interoperability
Duncan Johnston-Watt (Scribe): MartinC > Extensions could affect interoperability (as discussed yesterday)
Rich Miller (Cloudsoft): Apologies for joining late. Has there been a change in the WebEx meeting number? I am having difficulty
joining the meeting.
Duncan Johnston-Watt (Scribe): Anish > Interop "fest" is one way of figuring this out. Other TCs have found this useful.
Duncan Johnston-Watt (Scribe): @Rich > Voice Bridge: 866-682-4770 Code:
3005864 Passcode: CAMP
Rich Miller (Cloudsoft): I am on voice bridge. Just got on to the webex after the third try.
Duncan Johnston-Watt (Scribe): Jacques > Two aspects. Operations to be exercised and analysis of results
Duncan Johnston-Watt (Scribe): Jacques > Illustrated with Slide 13 from PPT - SUT stands for System Under Test
Duncan Johnston-Watt (Scribe): Phase 1: Test Operations (a) against an SUT in isolation (conformance); (b) against multiple SUTs in
matrix (interop); and (c) maintenance testing
Duncan Johnston-Watt (Scribe): Phase 2: Execution trace input into analyzer which compares these with test assertions and generates
report
Duncan Johnston-Watt (Scribe): Jacques > Now showing Slide 4
Duncan Johnston-Watt (Scribe): Jacques > Role of test assertions - these are derived from test suite and address one or more
normative statements in spec (act as a bridge between two teams - spec authors and test suite
authors)
Duncan Johnston-Watt (Scribe): Roshan > Does this imply there is a reference client executing the operations
Duncan Johnston-Watt (Scribe): Jacques > Although test assertions are intended to be abstracted away from implementations there
will need to be a client
Duncan Johnston-Watt (Scribe): Anish > In other standards work we tag statements in spec
Duncan Johnston-Watt (Scribe): Anish > Cross reference test assertions against these statements
Duncan Johnston-Watt (Scribe): Jacques > Referencing WSI document
Tom Rutt (Fujitsu): wsi BP 2.0
http://ws-i.org/Profiles/BasicProfile-2.0-2010-11-09.html
Duncan Johnston-Watt (Scribe): Jacques > Embedded links to test assertions embedded in spec and vice versa
Duncan Johnston-Watt (Scribe): Duncan > This looks like a maintenance headache
Duncan Johnston-Watt (Scribe): Anish > Wants to introduce Software Component Architecture (SCA) as a cleaner way of dealing with
this
Ashok Malhotra (Oracle): Martin, I'm on the call BTW
Duncan Johnston-Watt (Scribe): Anish > Here is the link http://docs.oasis-open.org/opencsa/sca-assembly/sca-assembly-1.1-spec.pdf
Duncan Johnston-Watt (Scribe): See for example Section 3 and Appendix C
Duncan Johnston-Watt (Scribe): Anish > Here is the test assertions doc http://docs.oasis-open.org/opencsa/sca-assembly/sca-
assembly-1.1-test-assertions-cd01.pdf
Duncan Johnston-Watt (Scribe): See for example 1.1 (format) and 2.1
Adrian Otto (Rackspace): Please mute your microphones when not speaking on the bridge.
Duncan Johnston-Watt (Scribe): Jacques is now walking us through first example in 2.1 Section 4
Duncan Johnston-Watt (Scribe): Adrian > Source referenced for a Assertion ID should be specific
Duncan Johnston-Watt (Scribe): IE Source should be a normative statement (or list of statements)
Duncan Johnston-Watt (Scribe): Tom > Important to note that it is in the test assertion that we specify the actual target
Duncan Johnston-Watt (Scribe): Anish/MartinC > In this example we are testing a constraint that cannot be captured in schema
Adrian Otto (Rackspace): The preferred style:
Duncan Johnston-Watt (Scribe): Adrian > Suggests a terser style
Adrian Otto (Rackspace): Assertion ID = TA-10
Adrian Otto (Rackspace): Source = S-12
Adrian Otto (Rackspace): Prerequisites: TA-9 must pass
Adrian Otto (Rackspace): so, no zeropad for numbers and we use a short prefix of TA- or S- to indicate which references are sources
(S) or test assertions (TA)
Duncan Johnston-Watt (Scribe): Jacques > Adrian has highlighted important point that TAs may have other TAs as prerequisites
Duncan Johnston-Watt (Scribe): Switching to CAMP TC test assertions draft
Duncan Johnston-Watt (Scribe): Jacques is discussing 3.1 Example
Duncan Johnston-Watt (Scribe): Roshan> Section references will change?
Duncan Johnston-Watt (Scribe): Tom > Will be replaced by Tags to address this
Duncan Johnston-Watt (Scribe): (Context - NormativeSource)
Duncan Johnston-Watt (Scribe): Anish > ,ar
Duncan Johnston-Watt (Scribe): Anish > Large number of targets?
Duncan Johnston-Watt (Scribe): Tom > Target should thing that is subject of test (which may not be SUT)
Tom Rutt (Fujitsu): The Predicate operates on the "target". The target may be an artifact which was generated by the SUT.
MartinC : from:
http://docs.oasis-open.org/templates/TCHandbook/ConformanceGuidelines.html
MartinC : Conformance Target an artifact such as a protocol, document, platform, process or service, which is the subject of
Conformance Clauses and Normative Statements. There may be several Conformance Targets defined within a specification, and
these targets may be diverse so as to reflect different aspects of a specification. For example, a protocol message and a protocol
engine may be different targets.
Duncan Johnston-Watt (Scribe): Rich > What assumptions (if any) are we making about implementing these tests - using automation
tools?
Standardizing on reports? etc
MartinC : this is intended to be different from a testing target - but i agree with tom the using "target" for both can be confusing
Duncan Johnston-Watt (Scribe): Jacques > Good question. While the TAs are abstract they need to be easy to implement.
Duncan Johnston-Watt (Scribe): Jacques > SUT (Provider) to be treated as black box - hence focus on messages
Duncan Johnston-Watt (Scribe): Tom > Which in turn means we need to think about feasibility of the TAs (messages will need to be
generated, PDPs created etc etc)
Duncan Johnston-Watt (Scribe): Alex > TAs should be consumable by automated test engine ideally - example we are looking at
(second one in
3.1 in draft)
Duncan Johnston-Watt (Scribe): ... fits this model better
Duncan Johnston-Watt (Scribe): Anish > Need to make a decision - are we going to adopt tagging (following sca-assembly approach)
Duncan Johnston-Watt (Scribe): MartinC > granularity of tagging is still important
Duncan Johnston-Watt (Scribe): Ashok and Rich have both squawked - will be added to Roll Call
Duncan Johnston-Watt (Scribe): Now breaking. Reconvening 11AM CST
Duncan Johnston-Watt (Scribe): Meeting resumed
Gershon Janssen: I'm on the call now...
Duncan Johnston-Watt (Scribe): Change to agenda - We are wrapping up test assertions discussion and then moving on to TC timeline
& planning
Duncan Johnston-Watt (Scribe): Issue proposals for 38, 10, 9 and 42 now scheduled for 1.30PM CST
Duncan Johnston-Watt (Scribe): Hard stop @ !2 Noon
Duncan Johnston-Watt (Scribe): s/!2/12
Duncan Johnston-Watt (Scribe): Gershon squawked - will be added to Roll Call
Duncan Johnston-Watt (Scribe): MartinC > Need to wrap up test assertions discussion and decide on tagging so that authors can
proceed
Duncan Johnston-Watt (Scribe): MartinC > Rewrite of spec also required / implied by decision
Duncan Johnston-Watt (Scribe): Adrian > To submit issue
Duncan Johnston-Watt (Scribe): MartinC > normative statements need to be labelled (scope of labelling may vary) in order to feature
in a test assertion
Duncan Johnston-Watt (Scribe): MartinC > Discussion of RFC/ISO to be part of discussion of new issue CAMP-45 Normative Statement
overhaul
Duncan Johnston-Watt (Scribe): (opened by Adrian)
Duncan Johnston-Watt (Scribe): s/opened/added/
Duncan Johnston-Watt (Scribe): Now considering
https://tools.oasis-open.org/issues/browse/CAMP-45
Duncan Johnston-Watt (Scribe): Adrian moves to open CAMP-45
Duncan Johnston-Watt (Scribe): Anish seconds
Duncan Johnston-Watt (Scribe): Gil > Figuring out what we mean by consistent style is part of resolving this issue
Duncan Johnston-Watt (Scribe): Sidebar: MartinC agreed to log issue re conformance target versus testing target
Duncan Johnston-Watt (Scribe): Discussion regarding ensuring spec is acceptable as ISO standard
Duncan Johnston-Watt (Scribe): No further discussion
Duncan Johnston-Watt (Scribe): No objections
Duncan Johnston-Watt (Scribe): CAMP-45 opened
Duncan Johnston-Watt (Scribe): Now resuming test assertions discussion
Duncan Johnston-Watt (Scribe): Jacques is discussing second example in 3.1
Duncan Johnston-Watt (Scribe): This is more general (parameterized) version of original example
Duncan Johnston-Watt (Scribe): Adrian > Would this TA still hold wrt extensions? If so how?
Duncan Johnston-Watt (Scribe): Jacques > Needs further discussion
Duncan Johnston-Watt (Scribe): Now considering 3.2 Protocol Test Assertions
Duncan Johnston-Watt (Scribe): Jacques > Ideally we would like to obtain meta-data in the same way EG via a plain GET
Duncan Johnston-Watt (Scribe): Tom > Normative source here is no longer just a label but includes derivation for testing purposes
Duncan Johnston-Watt (Scribe): Jacques > Derivation is the correct term
Duncan Johnston-Watt (Scribe): Meeting breaking for lunch
Duncan Johnston-Watt (Scribe): Resuming 1PM CST
MartinC : we will resume at 1:10 pm cst
MartinC : bridge is open
Scribe(Fujitsu): scribing
Scribe(Fujitsu): scribing
Scribe(Fujitsu): Topic: review timeline
Scribe(Fujitsu): Anish: need to establish exit criteria
Scribe(Fujitsu): chair: typically, CS level: every feature need be implemented twice
Scribe(Fujitsu): Adrian: test suite relationship? conformance requirement?
Scribe(Fujitsu): Adrian: how do we define "feature"?
Scribe(Fujitsu): Adrian: (read charter) TC defines exit criteria. At
minumum: 2 interoperable impl of both kinds (COnsumer/Provider) must impl every mandatory feature, etc...
Scribe(Fujitsu): jacques: implicitly, interoperable exchanges assume they are agreed to be conforming (according to test assertions)
Scribe(Fujitsu): test assertions will be a CN (not CS)
Scribe(Fujitsu): Duncan: CloudOpen is coming up - could be the event where we publicize CAMP (Sept 16-1
Duncan Johnston-Watt (Cloudsoft): See
http://events.linuxfoundation.org/events/cloudopen
Scribe(Fujitsu): Anish: mandatory vs optional: a "feature" will map to several normative reqs.
Duncan Johnston-Watt (Cloudsoft): Sounds like there is general agreement that interoperability testing has to be scenario-based
(Adrian, Anish et al)
Scribe(Fujitsu): ... testing: we created scenarios exercising specific features
Scribe(Fujitsu): Duncan: keep the bar to a feasible level (dont want to miss exit criteria because of high bar)
Scribe(Fujitsu): ... a core set of features / reqs could be defined.
Scribe(Fujitsu): chair: optionality of behavior not same as optionality of support.
Scribe(Fujitsu): Anish: publish early & often...
Scribe(Fujitsu): chair: 3 delivery lines (internal + external): (1) main spec, (2) test assertions, (3) implementations/interops
Scribe(Fujitsu): chair: 1st PR: all P1 issues resolved is a prereq
Scribe(Fujitsu): Testing = {TA document + test scenarios + test suite }
Scribe(Fujitsu): the TA document timeline must be most closely tied to core spec timeline - but may lag behind a couple weeks.
Scribe(Fujitsu): Tom: interop demo does not rely on the [conformance] test suite ?
Scribe(Fujitsu): Anish: any interop exercise must be validated by test scenarios and comply with test assertions
Scribe(Fujitsu): chair: plugfest 1 : around 1st PR time, plugfest 2:
qualifies for exit criteria.
Scribe(Fujitsu): roshan: implementations should be more precisely scheduled on the tmeline: we need to plan for having qualifying two
impl.
Scribe(Fujitsu): chair: who is implementing?
Scribe(Fujitsu): Adrian: Rackspace focusing for now on the actual underlying functions - not so much on [CAMP] API. The API priority
level is less than the layer underneath. RSpace may decide to make it an open-source project too.
Scribe(Fujitsu): A fork of the original OSS can be considered as a separate implementation?
Scribe(Fujitsu): chair: we can change the charter if needed (without breaking the spirit of the law)
Scribe(Fujitsu): ... deadline we work on: CS approval.
Scribe(Fujitsu): Duncan: tentative: early September for CS. Meaning 7 month for tech work.
Scribe(Fujitsu): anish: end of May for 1st PR?
Scribe(Fujitsu): chair: proposed timeline:
Scribe(Fujitsu): ... 1st April= closing deadline for P1 issues
Scribe(Fujitsu): ... 1st June: 1 PR startd
Scribe(Fujitsu): ... 1st August: all issues on JIRA closed, 2nd PR
Scribe(Fujitsu): ... 1st September: CS ballot started
Scribe(Fujitsu): .. candidate F2F dates: 1st week april, mid-July,
Scribe(Fujitsu): ... OS is off chart for now (tentative 1Q 2014)
Scribe(Fujitsu): ... CS (Committee Spec) plan for early September approval.
Scribe(Fujitsu): topic: issue prioritization
Scribe(Fujitsu): ... when opening issues, we'll assign priority.
Scribe(Fujitsu): ... considering "open" issues only: 29 issues
Scribe(Fujitsu): camp#1:
Scribe(Fujitsu): critical (P1)
Scribe(Fujitsu): critical (P1)
Scribe(Fujitsu): Gil yawning
Scribe(Fujitsu): task = editorial task
Scribe(Fujitsu): so: camp#1= "critical(P1) + task)
Scribe(Fujitsu): (major is P2 , minor is P3)
MartinC - webex1:
https://oracleconferencing.webex.com/oracleconferencing/e.php?
AT=WMI&EventID=219603472&PW=673fe83e435958590e&RT=MiM0
Scribe(Fujitsu): Gil: can we get window machine play "the girl from Ipanema"?
Scribe(Fujitsu): Gil displays a prioritization proposal.
Scribe(Fujitsu): #1,4,10,14 are related
Scribe(Fujitsu): ... along with #39: all about extensibility.
Scribe(Fujitsu): ... proposed to be P1.
Scribe(Fujitsu): #26: proposed to be P3
Scribe(Fujitsu): camp#11: proposed to be P2
Scribe(Fujitsu): MOTION (Alex, 2nd: Gil) that we adopt the proposal table displayed.
jeffm: he asked if there were any ?'s on the phone
jeffm: silence is golden
Scribe(Fujitsu): no discussion.
Scribe(Fujitsu): no objection: UNAN approved.
Scribe(Fujitsu): chair: assignment to owners.
Scribe(Fujitsu): ===== #1: P1
Scribe(Fujitsu): ===== #3: P1, Anish
Scribe(Fujitsu): ===== #4: P1, adrian
Scribe(Fujitsu): ===== #5: P2, Gil
Scribe(Fujitsu): ===== #9: P2, Alex
Scribe(Fujitsu): ===== #10: P1, adrian (+ change title "extension scheme")
Scribe(Fujitsu): ===== #11: P2, Alex
Scribe(Fujitsu): ===== #14: P1, Gil
Scribe(Fujitsu): ===== #16: P3, ?
Scribe(Fujitsu): ===== #17: P1, Tom
Scribe(Fujitsu): ===== #18: P2, Gil
Scribe(Fujitsu): ===== #19: P3, adrian
Scribe(Fujitsu): ===== #20: P2, Gil
Scribe(Fujitsu): ===== #21: P1, Gil
Scribe(Fujitsu): ===== #22: P2, Gil
Scribe(Fujitsu): ===== #23: P2, Gil
Scribe(Fujitsu): ===== #26: P3, Mark
Scribe(Fujitsu): ===== #27: P3, Gil
Scribe(Fujitsu): ===== #28: P2, adrian (link to #10)
Scribe(Fujitsu): ===== #29: P2, Gil
Scribe(Fujitsu): ===== #30: P1, adrian
Scribe(Fujitsu): ===== #31: P2, jacques
Scribe(Fujitsu): ===== #34: P1, adrian
Scribe(Fujitsu): ===== #36: P1, adrian
Scribe(Fujitsu): ===== #37: P2, Mark
Scribe(Fujitsu): ===== #28: P2, Gil
Scribe(Fujitsu): ===== #39: P1, adrian
Scribe(Fujitsu): ===== #40: P2, gil
Scribe(Fujitsu): ===== #45: P1, editors
Scribe(Fujitsu): ... end of list
Scribe(Fujitsu): topic: new issues
Scribe(Fujitsu): ===== #41: dupe #34. Anish MOVES to close, adrian 2nd.
No discuss/obj. approved
Scribe(Fujitsu): ===== #42: (alex) discussed: Tobias has reservations
Scribe(Fujitsu): MOTION: (alex, 2nd adrian) to open as P2, assign to alex. UNAN approved.
Scribe(Fujitsu): ===== #43: issue will be duplicate of adrian's
Scribe(Fujitsu): MOTION: (adrian, 2nd alex) to close 43 as a dup of #4.
Scribe(Fujitsu): UNAN approved.
Scribe(Fujitsu): ===== #44: (alex)
Scribe(Fujitsu): adrian: discovery for types could address this? maybe
Scribe(Fujitsu): tom: clarify the issue (resource type)
Scribe(Fujitsu): MOTION: (alex, 2nd duncan), to open, linked to #39 and #1.
Scribe(Fujitsu): ... with P3 level
Scribe(Fujitsu): UNAN approved.
Scribe(Fujitsu): ===== #46: (martin)
Scribe(Fujitsu): MOTION: (tom, 2nd anish) to open P2 level, assigned to Jacques.
Scribe(Fujitsu): UNAN approved.
Scribe(Fujitsu): break (4:20pm, for 5mn)
Scribe(Fujitsu): topic: issue technical discussion
Scribe(Fujitsu): topic: camp #10
Scribe(Fujitsu): adrian: discuss his proposal
Scribe(Fujitsu): anish: if use HTTP URL, similar restriction is required. Can drop the section.
Scribe(Fujitsu): adrian: extensions will always be used (e.g. needed by
auth)
Scribe(Fujitsu): ... consensus that the notion of "prefix" (for attr
names) is not a key concept in CAMP, just a best practice to avoid name collisions.
Alex Heneveld (Cloudsoft): Where an extension wishes to support one or more additional formats, these formats MUST be supported
for all resources defined in the spec.
Scribe(Fujitsu): jacques: import/export ops may have to deal with different formats than the one(s) claimed to be supported.
Scribe(Fujitsu): jacques: import/export ops may have to deal with different formats than the one(s) claimed to be supported.
MartinC lowered your hand
Scribe(Fujitsu): discussion on not exceeding the scope of the spec.
Mark Carlson (Oracle) lowered your hand
Scribe(Fujitsu): discussion about difference between "features" and "extensions" (different data structure?)
jeffm: i need to defer speaking for a sec, got another call
jeffm: ok, im back
Scribe(Fujitsu): adrian to repost an updated proposal (camp #10), for candidate motion tomorrow.
Scribe(Fujitsu): topic: camp #38
Scribe(Fujitsu): discussion on the "control status" values, and meaning.
Mark Carlson (Oracle): The controlStatus attribute expresses certain restrictions on this resource based on underlying activities as
shown in Table X below.
jeffm: I think anish is correct
MartinC lowered your hand
Scribe(Fujitsu): adrian: error state has value in a distributed system
Tom Rutt (Fujitsu): perhaps "representationStatus" is a better name for this common attribute rather than "controlStatus"
MartinC : i prefer barneyStatus
Mark Carlson (Oracle): The controlStatus attribute expresses certain restrictions on this resource based on underlying activities as
shown in Table X below.
Mark Carlson (Oracle): The activityStatus attribute expresses certain restrictions on this resource based on underlying activities as
shown in Table X below.
Scribe(Fujitsu): chair: #38 needs more work on proposal.
Scribe(Fujitsu): chair: meeting recessed for the day.
jeffm: what time in the AM?
Gil: can someone post the WebEx URL?
Roshan Agrawal (Rackspace): I seem unable to get into the call bridge. I tried +1 866-682-4770, conf Id conf id: 598-770-660#. Can
someone repost the dial-in details
Tobias Kunze (Red Hat): Webex:
Meeting Number: 598 770 660
Meeting Password: 2267
https://oracleconferencing.webex.com/oracleconferencing/j.php?J=598770660&PW=NZDFmYzZlMDI2
Tobias Kunze (Red Hat): conf id is 3005864
Tobias Kunze (Red Hat): pass is 2267
MartinC - webex: https://oracleconferencing.webex.com/oracleconferencing/e.php?
AT=WMI&EventID=219603472&PW=c7af56b1f54153527b&RT=MiM0
jeffm: blah, blah, blah
jeffm: hey i have a 22 year old car
jeffm: it still works ? mostly
jeffm: it doesn't have blue tooth
Adrian Otto (Rackspace): I have a truck from 1978!
Gil: you are a traitor to the economic well-being of our nation
Gil: go review "The Story of Stuff" to clarify your role in society
jeffm: i have clarified my role
Mark Carlson (Scribe): Meeting has been recalled from recess
Mark Carlson (Scribe): Chair: any new people to add to the roll?
Mark Carlson (Scribe): Adrian: Need to nod on issue 39, plus update proposals for 10 and 14.
Mark Carlson (Scribe): Adrian: also added a comment on another issue
Mark Carlson (Scribe): Alex: Issue 9 - discuss proposal
Mark Carlson (Scribe): Alex: propose a generic "operations" attribute with OperationName:Link entries
Mark Carlson (Scribe): Alex: Get fetches a ResourceOperation resource type with description and map values
Mark Carlson (Scribe): Alex: POST invokes the operation, taking a map for parameters
Tobias Kunze (Red Hat): @markc didn't hear the roll call. do you have me?
Roshan Agrawal (Rackspace): Same for me. Do you have me in the roll today/
MartinC : theres only one roll for the three days - so we only need to ask for new people to be added
Roshan Agrawal (Rackspace): cool. thanks MArtin
Mark Carlson (Scribe): @tobias and @roshan - there is one "roll" for the whole week.
Tobias Kunze (Red Hat): @markc copy that
Mark Carlson (Scribe): Adrian: needs to work for extensions as well.
Mark Carlson (Scribe): Anish: would they be the same link?
Mark Carlson (Scribe): Alex: the client doesn't care
MartinC : rest wars
Mark Carlson (Scribe): Adrian: could get operations metadata the same way as CAMP-1
Mark Carlson (Scribe): Gil: do operations by updating the resource directly
Mark Carlson (Scribe): Gil: see comment I added to the issue. Put all the sensors in a sub resource that is not affected by the effectors
changing
Mark Carlson (Scribe): Alex: It's more clear with specific URLs
Tobias Kunze (Red Hat): +1 on Gil's comment
Mark Carlson (Scribe): Jacques: Are URIs well formed and non-opaque?
Tobias Kunze (Red Hat): Consensus so far was that URLs are HATEOAS
Tobias Kunze (Red Hat): ie opaque
Mark Carlson (Scribe): Alex: we should continue to NOT dictate the URL structure
Mark Carlson (Scribe): Tom: URLs are not identities. The data is "state". I like PATCH for operations.
Mark Carlson (Scribe): Tom: what happens when you do a GET against the operation URL?
Mark Carlson (Scribe): Tom: in support of Alex's proposal
Mark Carlson (Scribe): Tobias: makes sense to keep things fine grained at the lowest level.
Jacques (Fujitsu): in a world where there is a large number of similar objects (dtabases...), single-URI resources + actions-as-
parameter, make sense. But here, "resources" are different kind of objects, probably smaller scale than DB records/objects. The
operation-as-resource approach flexibility can make more sense.
MartinC : OCCI slides: https://docs.google.com/presentation/d/122sQ-lQzeBadyFoeED-h341Dh8fqJQZChk6QQLm-0M0/edit
Charlie Tupitza JumpSoft: much better clarity today
Mark Carlson (Scribe): Meeting is recalled from OCCI recess
Mark Carlson (Scribe): Short break.
Jacques (Fujitsu) uploaded file: going-down-the-drain.jpg
Jacques (Fujitsu) uploaded file: rackspace-typical-profile.jpg
Mark Carlson (Scribe): Camp-42 under discussion
Mark Carlson (Scribe): Alex has an updated proposal.
Mark Carlson (Scribe): Propose query parameters to scope what is returned
Mark Carlson (Scribe): Martin: split out the two issues?
Mark Carlson (Scribe): Alex: it can get very complicated
Mark Carlson (Scribe): Jacques: is this convention used elsewhere?
Mark Carlson (Scribe): Alex: have not copied it from somewhere else...
Mark Carlson (Scribe): Adrian: investigate byte-range as a way to get number of characters, but if you want to count records that
would be a useful addition
Mark Carlson (Scribe): Jacques: separate what you are selecting and what is returned for your selection
anish adrian, the accept-range header is a server-side header, which tells the client what it can do with ranges. Range is the correct
http client-side header to request a specific byte-rante
Mark Carlson (Scribe): Gil: may have implications on how we structure the resources for metrics/affectors
Mark Carlson (Scribe): Martin: normative definition for RegEx
Mark Carlson (Scribe): CAMP 42 should proceed with a more details concrete proposal along the proposed lines
Mark Carlson (Scribe): CAMP 30 under discussion
Mark Carlson (Scribe): Adrian: soliciting feedback on the proposal in the issue comment
Mark Carlson (Scribe): Anish: this doesn't allow instance attributes that are not in the Template
Mark Carlson (Scribe): Anish: have a special attribute in the template that lists all the Assembly attributes that are parameterizable
Mark Carlson (Scribe): Adrian: will update the proposal
Mark Carlson (Scribe): Roshan: did not see a way to create some attributes
Mark Carlson (Scribe): Adrian: revised proposal will make that clear
Mark Carlson (Scribe): Jacques: support for writable on the instance type gives us what we need
Mark Carlson (Scribe): Adrian: how is that supplied over and above the value in the template?
Mark Carlson (Scribe): CAMP 30 should proceed with a more detailed concrete proposal along these lines, discussion closed for now
Mark Carlson (Scribe): CAMP-14 under discussion
Mark Carlson (Scribe): Adrian: took out reference to deployment plan as being an XML file
Mark Carlson (Scribe): Adrian: added a supported formats URI in 5.6 Platforms
Mark Carlson (Scribe): Adrian: added 5.17 Format resource
MartinC : CAMP-2 What is the purpose of the Definitions attribute? has already been resolved - editors need to apply
Mark Carlson (Scribe): Adrian: if you have a formats URI, there must be at least the JSON format defined
Mark Carlson (Scribe): Adrian: this allows you to not have to special case the existing format when multiple exist
Mark Carlson (Scribe): Gil: the version is too cute. Just have a new format for the two versions
Mark Carlson (Scribe): Gil: what will the client do with the version information?
Mark Carlson (Scribe): Adrian: it will match it's search for what it is coded for
Mark Carlson (Scribe): Adrian: example is if my format needs to break with older clients of it
Mark Carlson (Scribe): Adrian: Formats is a singleton that collects all the format resources
Mark Carlson (Scribe): Anish: we are establishing a pattern of always creating new resources for finding extensible lists
Mark Carlson (Scribe): Adrian: since Discovery is done so rarely, this prematurely optimizes for a good reason
Mark Carlson (Scribe): Jeff: JSON should always be the first element
Gil: q
Mark Carlson (Scribe): Adrian: added text to require this
Mark Carlson (Scribe): Adrian: deleted text that looked like a normative statement to use content negotiation
Mark Carlson (Scribe): Adrian: should we end the name of these attributes with "Uri"? - no disagreement
Mark Carlson (Scribe): MOTION (m:adrian s:gil) use camp-14-2013-1-24-r3.doc to resolve issue CAMP-14
Mark Carlson (Scribe): UNAN
Adrian Otto (Rackspace): Correction for the doc referenced by the prior motion: https://www.oasis-
open.org/apps/org/workgroup/camp/download.php/48022/camp-14-2013-01-24_r4.doc
Mark Carlson (Scribe): Demo from Gil
Roshan Agrawal (Rackspace): Adios, breaking for lunch.
Rich Miller (Cloudsoft): Could you please record the proposed dates in the chat log?
Mark Carlson (Scribe): Proposed next face to face April 4th-5th. 15 people. Possible Portland, OR or San Jose, CA
Rich Miller (Cloudsoft): Thank you.
anish: rich can u hear us?
anish: can u read this in the chat?
MartinC : anyone on the phone bridge?
Rich Miller (Cloudsoft): Yes, I hear you.
anish: can u speak?
Rich Miller (Cloudsoft): Yes, I do understand that.
anish: looks like we can't hear you
Rich Miller (Cloudsoft): I got the dates.
Rich Miller (Cloudsoft): Question of Co-Chair was unclear.
Alex Heneveld (Cloudsoft): 3rd, 4th, and 5th
Mark Carlson (Scribe): Rental Car Return location: Location:
W Cargo
Crownhill Park TX
View location:
Open in Google Maps http://maps.google.com/maps?q=W%20Cargo@29.532130,-98.483060
Alex Heneveld (Cloudsoft): Martin says he would welcome a co-chair if anyone is interested and available.
Rich Miller (Cloudsoft): Ah. Got it. Tom is co-chair pro tem for meeting in 2 weeks (?). Independent question is a standing Co-Chair.
Will discuss with Duncan and others.
Rich Miller (Cloudsoft): No, no longer on the queue
Mark Carlson (Scribe): Tom Rutt appointed interim Pro-Tem chair for the meeting on February 6th (m: martin, s:anish) UNAN
Mark Carlson (Scribe): Meeting Adjourned. Thanks to Rackspace for hosting and dinner.
Duncan Johnston-Watt (Cloudsoft): +1
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]