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
>
CmHome
>
CmSpecificationIssueTracking
(revision 22) (raw view)
---+ OSLC-CM Specification Issues and Comments List of general comments or issues against the specification development for the Change Management domain. Spec comments being worked (Closure description included after each comment, with prefix <font color="limegreen">CLOSED</font>. If unresolved or spec needs to be updated, it will have a prefix of %RED%OPEN%ENDCOLOR% ) ---++ Submitting Comments To make sure that comments and issues are appropriately raised, send them directly to [[http://open-services.net/mailman/listinfo/oslc-cm_open-services.net][oslc-cm@open-services.net] detailing which specification, section and issue. If desired, you can also add it to the list below for tracking. ---+++ After OSLC-CM 1.0 specs were finalized: %RED%OPEN%ENDCOLOR%<br /> * PatrickStreule 1 %RED%OPEN%ENDCOLOR% Unnecessary (and problematic) quotes in sample in http://open-services.net/bin/view/Main/CmQuerySyntaxV1#Selecting_properties_and_inlinin<br /><pre>?oslc_cm.query=state="open"&oslc_cm.properties="dc:title,dc:owner{*}"</pre><br />should be<br /><pre>?oslc_cm.query=state="open"&oslc_cm.properties=dc:title,dc:owner{*}</pre> * IanGreen namespace prefixes are misleading in selective properties. e.g., in <br /><pre>?oslc_cm.query=state="open"&oslc_cm.properties=dc:title,dc:owner{*}<br />the interpretation of "dc" is ambiguous. i would suggest a fully-expanded form, but worry about long URIs. similar goes for JSON, though in that case the spec is explicit<br /><br />Proposal: Need to something like ?oslc_cm.namespace=dc==http://purl.org/dc/terms/,jfs=http://jazz.net/xmlns/foundation/1.0/<br /></pre> * MartinNally see [[http://open-services.net/pipermail/oslc-cm_open-services.net/2009-November/000044.html][message from 23-Nov]] * RobertElves strong desire to have sample of query response with embedded ChangeRequest in ATOM format * Query Spec introduction discusses a "limit" parameter but not in spec. This "limit" capability is really defined in [[CmRestApiV1#Get_a_collection_of_change_reque][Cm REST API]] as the oslc_cm:pageSize parameter. * [[http://open-services.net/pipermail/oslc-cm_open-services.net/2010-January/000074.html][Ferran Rodenas CM Service Description doc is not RDF/XML valid]] * Handling of delegated web UIs: sample with frame and event source test assumes a spec requirement but there is no supporting spec [[http://open-services.net/bin/view/Main/CmDelegatedResourceSelectionAndCreationV1?#Observer_Responsibilities_for_Po][see section]]<pre>e.source == frame.contentWindow</pre> <br /><font color="limegreen">CLOSED</font> * SteveSpeicher 1 <font color="limegreen">CLOSED </font>Inconsistency with http://open-services.net/bin/view/Main/CmRestApiV1?sortcol=table;up=#Managing_multi_valued_properties<br />The sample in the end of the section conflicts with the statement: "Individual entries in the collection are not modeled as uniquely identifiable resources (referencable by a URI) " <br />Suggested correction:<br /> Remove the last sample inline entry that reads:<br /><p> To inspect an individual link contents, we can modify the request to provide inline properties such as: </p><pre>GET /records/12234-123344/blockedBy?oslc_cm.properties=blockedBy{*}<br />Accept: application/xml<br />Content:<br /><blockedBy oslc_cm:collref="/records/12234-123344/blockedBy"><br /> <blockedBy rdf:resource="/links/1255-235411"><br /> <dc:title>Bug 1234: Server DB issues</dc:title><br /> <url>http://remotesystem/bugs/1234</url><br /> </blockedBy><br /> <blockedBy rdf:resource="/links/123455-2344"><br /> <dc:title>Defect 4: Not handling out of diskspace problems</dc:title><br /> <url>/records/128312-12492</url><br /> </blockedBy><br /></blockedBy><br /></pre><br />Fixed in version: http://open-services.net/bin/view/Main/CmRestApiV1?rev=65<br />Per group decision: CmMeetings07222009 * ArthurRyman: * <font color="limegreen">CLOSED </font>1. http://open-services.net/bin/view/Main/CmRestApiV1?sortcol=table;up=#Introduction <br /><br />ajpplication <br /><br />should be <br /><br />application <br /><br />Fixed in version: http://open-services.net/bin/view/Main/CmRestApiV1?rev=65<br />Per group decision: CmMeetings07222009<br /><br /><br />2.<font color="limegreen">CLOSED</font> http://open-services.net/bin/view/Main/CmRestApiV1?sortcol=table;up=#Selective_Properties <br /><br />word ::= /any sequence of letters and numbers, starting with a number/<br /><br />should be <br /><br />word ::= /any sequence of letters and numbers, starting with a letter/ <br /><br />Fixed in version: http://open-services.net/bin/view/Main/CmRestApiV1?rev=65<br />Per group decision: CmMeetings07222009 ---+++ From OSLC-CM 1.0 spec finalization phase: * PatrickStreule (RTC Work Items) 1 Ensure concurrent modifications to resources are appropriately handled. Support ETag on GET, utilized on PUT and if does not match response with 412 precondition failed <br /><font color="limegreen" class="WYSIWYG_COLOR">CLOSED</font> WG agreed to add * SamPadgett (ClearQuest) 1 Need for standard error response element for attended resource creation (redirect URL for web presentation) <br />Proposed change is to add something generic, like: <span class="WYSIWYG_TT"><oslc_cm:link rel="alternate" type="text/html" href="record/creationDialog"/><br /></span><font color="limegreen" class="WYSIWYG_COLOR">CLOSED</font> Altered concept of "attended resource creation" to instead be "form factory". Updated CmRestApiV1, CmServiceDescriptionV1 and CmDelegatedResourceAndCreation<br /><font color="limegreen" class="WYSIWYG_COLOR">CLOSED</font> WG agreed to add <link> * SteveAbrams <blockquote>CmRestApiV1<br />Under "media types" on http://open-services.net/bin/view/Main/CmRestApiV1<br />there is a TODO for valid RDF/XML -- where are we on that?<br /><font color="limegreen" class="WYSIWYG_COLOR">CLOSED </font> validated sample and removed comment from spect<br />do we not have a dfinition for application/x-oslc-cm-change-request+json? or is this stricly XML?<br /><font color="limegreen" class="WYSIWYG_COLOR">CLOSED </font> spec updated with definition<br /> application/xml and application/json are still mentioned as formats under "http://open-services.net/bin/view/Main/CmRestApiV1#Create_a_new_change_request" -- I think you mean application/x-oslc-cm-change-request+xml and application/x-oslc-cm-change-request+jsonl there, although if so, we do need the spec for the JSON format.<br /><font color="limegreen" class="WYSIWYG_COLOR">CLOSED</font> Spec updated. WG agreed this would be required for POST<br />For attended resource ccreation, are we currently saying that you can either prpovide a 'ticket' or communicate back from the iFrame as in the picker case? If so, we're making our clients lives 2x as hard as they need to be, since they have to be prepared for either response.<br /><font color="limegreen" class="WYSIWYG_COLOR">CLOSED</font> Specs updated with "form factory" concepts. WG agreed to remove this<br />Under "Get a change request" -- you do specify that the json format is allowed, but don't say what it is. Also -- are we requiring that requests text/html and application/xhtml+xml be satisfied? Are we providing a web UI in response to those requests?<br /><font color="limegreen" class="WYSIWYG_COLOR">CLOSED</font>%RED% %ENDCOLOR%Yes, we are redirect to our Web UI presentations in these cases<br />"The formats returned MAY not represent the underlying service provider's data model." -- this actually doesn't make much sense to me; I'd strike it completely since we're not talking about underlying data models anywhere.<br /><font color="limegreen" class="WYSIWYG_COLOR">CLOSED</font>%RED% %ENDCOLOR%WG agreed to move this comment to an introductory section<br />Under "Update a change request" - media types need to be updated to fully-qualified oslc media types. I don't think we'll accept plain application/xml or application/json here, do you?<br /><font color="limegreen" class="WYSIWYG_COLOR">CLOSED</font> WG agreed to update with more specific media type for PUT<br />Under "Partial update of a change request" -- we should word this more clearly. http://foo.com/workitem/1234 is a different resource than http://foo.com/workitem/1234?propperties="headline" -- so this is not partial update of a change request: it's total update of a smaller resource. This may sound like a nit, but it's an important point (to me). Now that I think about it, we're surfacing the same incorrect mental model under both "Selected Properties" and "Response Properties" -- that should be phrased to reflect the fact that there are additional, logical resources that include only specific properties, with URLs that can be computed as described here. <br />%RED%OPEN%ENDCOLOR% need someone to take a pass at better wording<br />The "Selected Properties" discussion needs to be connected to the resources that support it in some way.<br />%RED%OPEN%ENDCOLOR%<br />On pagination: MUST be limited in size, or SHOULD be? I thought this was an advisory request...<br /><font color="limegreen" class="WYSIWYG_COLOR">CLOSED</font> change made<br />Where are we on the discussion of what the media types are for inlined and subsetted resources?<br />%RED%OPEN%ENDCOLOR% We have concluded that discussion with a result that we would not inline any resourse beyond the first level. If we do expand the first level, then only wildcard is supported. Action to make it clear that subsequent requests for inlined resources will use generic media type. For example, if requesting cr+xml and inlining a User resource, request its content with plain xml media types.<br /><br />OslcServiceProviderCatalogV1: <br />"The media type of a Service Provider Catalog Document is REQUIRED to be..." should say "MUST be"<br />%RED%OPEN%ENDCOLOR% According to RFC2119 MUST=REQUIRED, though we can reword to eliminate confusion<br />This doesn't use the table to describe the required and optional attributes as our other ones do; I don't know if it's worth adding that table at this point but it is an inconsistency.<br />%RED%OPEN%ENDCOLOR% Known, other things have taken priority and no one has updated<br /> CmServiceDescriptionV1<br />says to 'rewrite with OslcServiceProviderCatalogV1" but this still needs doing.<br /><font color="limegreen" class="WYSIWYG_COLOR">CLOSED</font> a todo<br />is this resource RDF/XML? <br /><font color="limegreen" class="WYSIWYG_COLOR">CLOSED</font> Yes, it validates with RDF/XML validators<br /><br /> CmResourceDefinitionsV1<br />Do we need to say that this resource accepts 'open content'? Or something to indicate that it MAY contain elemements not specified here, and indicate what the server should do when POSTs come in with additional content? Perhaps indicate in the "Introduction" here that the reason for this being a minimal resource.<br /><font color="limegreen" class="WYSIWYG_COLOR">CLOSED</font> spec updated that open conteWG agrees to update to make it clear that it supports open content </blockquote> * SteveSpeicher 1 Add text/xml support <br /><font color="limegreen" class="WYSIWYG_COLOR">CLOSED</font> updated spec CmRestApiV1 1 Add details about inlining resources in ATOM responses <br /><font color="limegreen" class="WYSIWYG_COLOR">CLOSED</font> update spec * ScottBosworth 1 Need to update JSON and XML <br />%RED%OPEN%ENDCOLOR% awaiting new samples 1 Take pass over all introductory sections of specs to provide better overview and context.<br />%RED%OPEN%ENDCOLOR% need contribution, some attempted like CmRestApiV1 * SamitMehta 1 Page: CmRestApiV1?sortcol=table;up=#Selective_Properties<br /><samit><br />Shouldn't <br />word ::= /any sequence of letters and numbers, starting with a number/<br />be<br />word ::= /any sequence of letters and numbers, starting with a letter/<br /></samit><br /><font color="limegreen" class="WYSIWYG_COLOR">CLOSED</font>%RED% %ENDCOLOR%%BLACK%updated spec%ENDCOLOR% 1 Page: CmRestApiV1?sortcol=table;table=up#Pagination<br />Question about Pagination: When collection results are provided limited by the request parameter of oslc_cm:pagesize, will subsequent requests with "next" or "previous" be required to return data based on the original query? <br />For example, one queries for all change requests and specifies a pagesize of 10 and the oslc_cm:totalCount returned is 100. Then someone submits a new change request. The URI for "next", returns another 10 records, but will the oslc_cm:totalCount be 100 or 101 in the next call.<br />I would presume that it should return continue to return data based on original query, but to be sure I would suggest that the above should be clarified in the spec.<br />%RED%OPEN %ENDCOLOR%%BLACK%clarify that server doesn't need to maintain state of the query%ENDCOLOR% 1 Page: CmRestApiV1?sortcol=table;table=up;up=#Attended_Resource_Creation<br />"inquiry" should be "inquire" in the sentence "... or a URL that can be used to inquiry about the status ...".<br /><font color="limegreen" class="WYSIWYG_COLOR">CLOSED</font>%BLACK% - removing attended resource creation%ENDCOLOR% 1 Page: CmRestApiV1?sortcol=table;table=up;up=#Managing_change_request_links<br />There are no specific standards described here for references, just examples. Wouldn't we want a standard on certain fixed references. It seems that the provider would define all the references via "custom" properties. Also the "links" themselves won't be a standard URL.<br />%RED%OPEN%ENDCOLOR% 1 Page: http://open-services.net/bin/view/Main/CmRestApiV1?sortcol=table;table=up;up=#Security_and_Authentication<br />Shouldn't the "Security and Authentication" be a "MUST" rather than a "SHOULD" or at least "MUST" support one of those mechanisms?<br />Also, is there any reason to include "Service consumers", since the rest of the document is really only talking about Service providers?<br /><font color="limegreen" class="WYSIWYG_COLOR">CLOSED</font> WG agreed that since these are HTTP-based methods and others are supported, SHOULD is the appropriate level of support 1 Page: http://open-services.net/bin/view/Main/CmRestApiV1?sortcol=table;table=up;up=#Error_Status_Information<br />typo "servier" to "service". <br /><font color="limegreen" class="WYSIWYG_COLOR">CLOSED</font> * %BLACK%NiravSheth%ENDCOLOR% 1 %BLACK%OSLC Query Syntax:%ENDCOLOR%%BLACK%The syntax should be like this oslc_cm.query=State="Open" instead of oslc_cm.query="State=Open"<br />%ENDCOLOR%<font color="limegreen" class="WYSIWYG_COLOR">CLOSED</font>%BLACK% agreed it should be corrected<br />%ENDCOLOR% 1 %BLACK%JSON Collections should include the oslc_cm:totalCount attribute to figure out how many total results can be reterived.<br />%ENDCOLOR%<font color="limegreen" class="WYSIWYG_COLOR">CLOSED</font>%BLACK% needs to be added%ENDCOLOR% * %BLACK%Other comments received and handled in previous meetings: CmMeetings05052009 CmMeetings04292009<br />%ENDCOLOR%
Edit
|
Attach
|
P
rint version
|
H
istory
:
r25
<
r24
<
r23
<
r22
<
r21
|
B
acklinks
|
V
iew topic
|
Raw edit
|
More topic actions...
Topic revision: r22 - 11 Jan 2010 - 20:18:54 -
SteveSpeicher
Main.CmSpecificationIssueTracking moved from Main.CMSpecificationIssueTracking on 31 Oct 2008 - 12:58 by
TWikiAdminUser
-
put it back
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