This wiki is locked. Future workgroup activity and specification development must take place at
our new wiki
. For more information, see
this blog post about the new governance model
and
this post about changes to the website
.
TWiki
>
Main Web
>
OslcCore
>
OslcCoreMeetings
>
OslcCoreMeetings05052010
(05 May 2010,
DaveJohnson
)
(raw view)
---+ OSLC Core Meeting May 5, 2010 ---++ Meeting logistics See the [[OslcCoreMeetings]] for more information, more dial-in numbers and on-line meeting information. * Conference Access * Toll free: 1-866-423-8350 * Toll: 1-719-387-8273 * Participant passcode: 558663 ---++ Agenda Today I would like to discuss the last two open issues: specification versioning and query representation. The issues are: * New versioning proposal resulting from special WG meeting last week: any questions or concerns? * http://open-services.net/bin/view/Main/OslcCoreMeetings04302010 * New Query capability example that illustrates how shapes work in relation to query: same question. * http://open-services.net/bin/view/Main/OslcCoreQueryDiscussion ---++ Meeting Minutes Attendees * DaveJohnson * JimConallen * ArthurRyman * ScottBosworth * NickCrossley On the topic of specification versioning * ScottB: make it clear that we are introducing a version number header is to differentiate Core with pre-Core, and to allow pre-Core clients to continue to work. Once specs conform to the Core, they can evolve without changing a version number string. * NickC: The no-header-v1-implied rule does not apply to domains that never had a v1 pre-Core version On the topic of specification versioning & Guidance for Designing resources * ScottB: guidance on properties applies to all, not just those that are required * ScottB: Good guideline is - if you think you need a property but cannot agree on type, then don't standardize it yet * DaveJ: Also - think you need a property then consider whether you want to support it forever * ScottB: need guidance for when you need to add a new capability; define a new service provider entry * e.g. new type of query, then define a new capability, =oslc_cm:SpecialChangeRequestQueryCapability= DaveJ: having to send an OSLC-Version header in a GET is obnoxious, can we add a =oslc-version= URL parameter On the topic of Query Capability discussion & need for shape * DaveJ: do you really have to list every type of resource as a member property, can we be generic * ArthurR: yes, you could have one member property that uses a "abstract base class" type of shape * NickC: we don't need to build any type hierarchy into the Core spec, we have what we need now to do generics like this * ScottB: do we really need to have a shape for a query capability, seems burdensome * ArthurR: its not unreasonably burdensome On the topic of Query Capability discussion * NickC: how much of the simple query syntax is really required by the Core? * ArthurR: different parts are specified MAY, SHOULD and MUST * DaveJ: we already do this, see how the Reporting spec defines which parts of Query it needs * ArthurR: add the "queryable" property back into oslc:Property. On the topic of Query Capability & Atom * DaveJ: does Atom feed representation look reasonable? * ArthurR: yes * ArthurR: Add a dc:description to oslc:ResponseInfo, it will be useful in some cases
E
dit
|
A
ttach
|
P
rint version
|
H
istory
: r3
<
r2
<
r1
|
B
acklinks
|
V
iew topic
|
Ra
w
edit
|
M
ore topic actions
Topic revision: r3 - 05 May 2010 - 15:50:47 -
DaveJohnson
Main
Main Web
Create New Topic
Index
Search
Changes
Notifications
RSS Feed
Statistics
Preferences
Webs
Main
Sandbox
TWiki
Български
Cesky
Dansk
Deutsch
English
Español
Français
Italiano
日本語
Nederlands
Polski
Português
Русский
Svenska
简体中文
簡體中文
Copyright � by the contributing authors. All material on this collaboration platform is the property of the contributing authors.
Contributions are governed by our
Terms of Use
Ideas, requests, problems regarding this site?
Send feedback