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
>
AmHome
>
ArchMgmtMeetings
>
ArchMgmtMeetings23Jun2011
(23 Jun 2011,
JimConallen
)
(raw view)
Date: *23 June 2011* <br />Time: *7:00 AM Pacific, 10:00 AM Eastern, 3:00 PM UK, 4:00 PM Frankfurt, 5:00 PM Haifa, 7:30 PM Bangalore* <br />Call In Number: (emailed)<br />Participation request: contact JimConallen ---++ Agenda 1 Review new open issue regrading link type properties 1 Plan the finalization activities 1 Review scenarios, ensure compatibility with 2.0 spec. ---++ Attendance Regrets: Alanna Zito Atendees: Clyde D Iscuspit, Daniel Berg, John Crouchley, Sandeep Kohli, Steve Speicher, Jim Conallen ---++ Minutes Jim C. opened up the meeting with the desire to start the last steps of finalization. Steve, a vetran of delivering OSLC specs, clarified the process. Jim and Steve will offline create the proper vocabulary document for OSLC AM resource defintions (in our case just AM Resource and Link Type Resource). After that an additional review by the core team might be in order, and with finished covenants we essentially just declare final. Jim, in what many might have thought a rather windy explanation, raised a new open issue regarding the use of the property types in the link type resource. Jim explained, the use of the link type resource, and compared it to the primary approach for obtaining human readable information about link type predicated (just GETting them in rdf form). Since purl.org and w3c.org provide machine readable resolutions on the URIs they define, we should be consistent with how they do it. So instead of using dcterms:title and description we use rdfs:label and rdfs:comment as they do. Given this changeis late in the game, it will not significantly affect the only know implementers (Design Manager, System Architect, and Rio). Everyone on the call was ok with this change. The next topic was a review of the summary of provider and client requirements. The only interesting discussion came in the section of authentication requirements. John raised the viewpoint of a third party client. It would be eaiser for them to know that at least one form of authentation would be available in all providers, citing OAuth as the most common one so far. Steve also pointed out that the CM specification has OAuth support as a SHOULD requirement, unlike the current MAY in the AM specification. We agreed to share this suggestion to the larger team via the list server, to get more comments. But the consensus from this group was to elevate provide OAuth authentication to a SHOULD level.
E
dit
|
A
ttach
|
P
rint version
|
H
istory
: r4
<
r3
<
r2
<
r1
|
B
acklinks
|
V
iew topic
|
Ra
w
edit
|
M
ore topic actions
Topic revision: r4 - 23 Jun 2011 - 15:17:30 -
JimConallen
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