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
>
QmHome
>
QmMeetings
>
QmMeetings20100726
(28 Jul 2010,
PaulMcMahan
)
(raw view)
---++ Date: 26 July 2010 ---+++ Agenda: * [[QmSpecV2Issues][spec issues]] resolved since last workgroup meeting * Collect any additional feedback from work group on current draft spec * OSLC Core: decision on RDF ---+++ Minutes: Attendance: IngridJorgensen, PaulMcMahan, ScottBosworth, NigelLawrence, ScottFairbrother, PaulSlauenwhite, ThomasNeal * Reviewed and agreed to RESOLVED on [[QmSpecV2Issues][spec issues]] answered since last workgroup meeting * Discussed relatedChangeRequest relationship properties. Should the spec use dcterms:relation instead? The workgroup like the idea of a general purpose relationship property such as this. But it is already defined in core so its available to service providers without necessarily including it in the QM spec. If later we find that it is needed for some particular scenario then we can explicitly add it to the QM spec. * Covered two additional items [[QmSpecV2Issues][spec issues]]: * Inconsistencies in the "Occurs" column of resource tables * AI: PaulMcMahan to correct and resolve issue * executablePath property of !TestScript. Why isn't it a relationship property? Main reason is because its value might be any type of identifier and maybe not a valid URI. For example UNC pathname. * AI: PaulMcMahan to investigate using a relationship property and resolve WI * Workgroup needs to consider whether the OSLC-Core-Version header should be *required* for the client to interact with OSLC V2 service provider, or if the oslc-qm-* Accept headers defined in the QM V1 spec would be sufficient for identifying QM V1 clients. The QM V1 spec was not really specific about the behavior when application/xml Accept header is sent, so whether this is safe of not depends on how clients of the V1 spec have been implemented. * AI: PaulMcMahan to investigate whether known clients of the V1 api sent the oslc-qm-* Accept header or if they sent application/xml. * Discussed new property of !TestExecutionRecord -- oslc_qm:configuration. Its purpose is to reference environment information (OS, hardware, etc) but does not specify a Range. Leaving Range unspecified rather than defining some new QM resource for allows adoption of future OSLC specification for configuration. This seems important since the concept of environment/configuration will probably span several domains (automation, change, etc). * Ideally a !TestExecutionRecord could also reference some type of Build resource. Workgroup decided to leave this unspecified now as the automation workgroup is still in the process of defining this type of resource. * The QM spec needs a summary table like is shown on the CM spec which clarifies the alignment/adoption of core spec * AI PaulMcMahan to add summary table * Discussed the core workgroup's position on mandatory RDF/XML. The QM workgroup is in favor of the mandate and will fully adopt it into QM V2 spec. * AI PaulMcMahan to add clarification of application/xml vs. application/rdf+xml to QM V2 sepc
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 - 28 Jul 2010 - 18:54:55 -
PaulMcMahan
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