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
>
OslcCoreV2Issues
>
OslcCoreV2ConvergenceIssues
(21 Sep 2011,
SteveSpeicher
)
(raw view)
---+ OSLC Core Spec V2 Issues (during Convergence phase) This document captures the issues raised against the OSLC Core Spec v2 during the convergence phase * OslcCoreSpecification - the OSLC Core Specification For the list of OSLC Core Spec v2 issues found during and after finalization see OslcCoreV2Issues page. ---+ DRAFT / Historical Issues These are the issues raised during the development of the OSLC Core spec up to finalization time. Note: dates below use US format (mm/dd/yyyy) Here's what the states mean: * %RED%OPEN%ENDCOLOR% - indicates that we have no response for the issue yet * %GREEN%RESOLVED%ENDCOLOR% - indicates that we have a response that we believe resolves the issue * CLOSED - issue has been resolved and the resolution has been reviewed by the WG * %ORANGE%DEFERRED%ENDCOLOR% - indicates that issue will be addressed in Core Guidance v1.0 during the month after the Core Specification is final. * %PURPLE%TABLED%ENDCOLOR% - indicates that issue will be reconsidered at some later but unspecified date ---+ Overall 1 %ORANGE%DEFERRED%ENDCOLOR% _Guidance - Resources with media content_ - can we add a recommended pattern for resources that have associated media files? E.g. Asset artifacts, change request attachments. (ScottBosworth, 03/04/2010) * *Response* Core WG will provide separate guidance on the File Descriptor or other pattern for this (DaveJohnson 03/18/2010) 1 %ORANGE%DEFERRED%ENDCOLOR% _Compact html representations_ - Should we add Core Spec guidance on protocol for UI rendering of hovers on links? The way Jazz does this is here <span style="font-family: verdana,helvetica,arial,sans-serif" class="Apple-style-span"><a target="_blank" href="https://jazz.net/wiki/bin/view/Sandbox/CompactRenderingV1P1" style="text-decoration: underline; cursor: pointer; color: #0000ff">https://jazz.net/wiki/bin/view/Sandbox/CompactRenderingV1P1</a></span> (ScottBosworth, 03/04/2010) * *Response* Yes but as separate guidance (DaveJohnson 03/18/2010) 1 %ORANGE%DEFERRED%ENDCOLOR% need guidance of how existing 1.0 specs can migrate (IanGreen, 03/03/2010) * *Response* Core WG will provide separate guidance and an Example OSLC Domain Spec as (DaveJohnson 03/18/2010) 1 %ORANGE%DEFERRED%ENDCOLOR% The Jazz notion of "Query Filters" is very useful, implementations of it exist and it should be included in the OSLC Core, documentation is here [[https://jazz.net/wiki/bin/view/Main/CALMFilters]] (from ErichGamma via DaveJohnson, 03/05/2010) * *Response* Yes but as separate guidance (DaveJohnson 03/18/2010) 1 CLOSED Overview - People are finding the relationship between shape and the factory and query confusing. I think we should maybe change it to this: each creation resource MAY have a resource shape, and each query resource MAY have a resource shape. (DaveJohnson for MN, 03/16/2010) * *Response* Changed to this model in the Overview section and in the Service Resource (DaveJohnson 03/18/2010) 1 CLOSED - need to make it clear that OSLC is intended to enable integration and not intended to be the end-all, comprehensive REST API for every OSLC domain (SteveSpeicher via DaveJohnson, 03/16/2010) * *Response* Second sentence in overview now reads "<span style="line-height: 20px; font-family: arial,verdana,sans-serif; font-size: 14px" class="Apple-style-span">The purpose of these specifications is to enable integration between products that support Application Life-cycle Management (ALM) and Product Life-cycle Management (PLM)</span>" (<span style="color: blue; text-decoration: underline">DaveJohnson</span> 03/18/2010) 1 CLOSED - we should work the term "loose coupling" into the design considerations section (SteveSpeicher via DaveJohnson, 03/16/2010) * *Response* Now use term loose coupling in the design considerations section (<span style="color: blue; text-decoration: underline">DaveJohnson</span> 03/18/2010) 1 CLOSED don't give impression that OSLC is only about ALM, its also about PLM (SteveSpeicher via DaveJohnson, 03/16/2010) * *Response* Now when we mention ALM we also mention PLM (<span style="color: blue; text-decoration: underline">DaveJohnson</span> 03/18/2010) 1 CLOSED Terminology inconsistency, in "Resource Creation" you refer to "Creation Resource" instead of "OSLC Creation Resource". This occurs in a few other places. (SteveSpeicher via DaveJohnson, 03/16/2010) * *Response* This comment is no longer relevant now that we use Creation Capability instead of Creation Resource (DaveJohnson 03/18/2010) 1 CLOSED There is no error handling or error reporting specified. A problem we found is that often clients would make a request for a JSON resource and get an error message in XML. It would be ideal to define a way that JSON errors be returned. Also, that there is a basic format for these error messages. See http://open-services.net/bin/view/Main/CmRestApiV1?sortcol=table;table=up#Error_Status_Information (SteveSpeicher via DaveJohnson, 03/16/2010) * *Response* Specified error response very similar to that in OSLC-CM v1 (DaveJohnson 03/24/2010) 1 CLOSED eTag handling / caching not mentioned in spec. Resource modifications and etag handling, it would be good to clarify usage of etag, 412 status codes and If-Match header: See http://open-services.net/bin/view/Main/CmRestApiV1#Update_a_change_request (SteveSpeicher via DaveJohnson, 03/16/2010) * *Response* No change. The If-Match header and 412 status code are already specified in the HTTP spec (DaveJohnson 03/23/2010) 1 CLOSED Need to cover how versioning works both for OSLC v1 to v2 transition and for subsequent version upgrades (DaveJohnson, 03/24/2010) * *Response* Added Specification Versioning section that describes how versioning works in the Core Spec and how old pre-Core services can continue to support old clients and also migrate to the new Core URIs (DaveJohnson 03/25/2010) 1 %GREEN%RESOLVED%ENDCOLOR% The Concepts and relationships diagram states that Query Capability provides base URI for 0..N Query Resource. Whereas, in the Service Provider Resources section, it states that a Query Capability has only-one oslc:queryURI. I believe the diagram is incorrect. (TackTong, 03/29/2010) *Response* No change. Diagram is correct, query capability has one query URI and it is the base URI for query resources provided by the capability (Dave Johnson 04/06/2010) 1 %GREEN%RESOLVED%ENDCOLOR% In Glossary of Terms, it states "OSLC Service: a set of capabilities that enable a web client to create, retrieve, update and delete resources managed by an ALM or PLM product or online service offering and associated with one OSLC Domain. " Would this statement be too restrictive that it will preclude, in the future, an OSLC Service that may provide capabilities that are cross-domains. E.g. A Query Capability for resources across multiple domains. (TackTong, 03/29/2010) * *Response* No change. A Service Provider can implement multiple OSLC domain specs, each Service implements one spec. This does not preclude a Service Provider from offering a Service that queries across multiple other services. (Dave Johnson 04/06/2010) 1 %GREEN%RESOLVED%ENDCOLOR% Throughout the spec, the term QName is used to describe property names and resource types. This is technically incorrect. Property names and resource types are URIs which we abbreviate used !PrefixedNames. In contrast, a QName is an XML concept that represents a pair consisting of a namespace URI and a localName NCName. When a property name is used in an XML document as an element or attribute name, we can represent it as a QName. The spec should make this distinction clear. (ArthurRyman 03/29/2010) * *Response* Spec rewritten to talk about Prefixed Names except when generating XML. (Dave Johnson 04/06/2010) 1 %GREEN%RESOLVED%ENDCOLOR% Does the specification allow more than one Service Provider per Domain to appear in the Service Provider Catalog? I.E. if there was more than one tool used for Quality Management, could both be registered in the same Catalog? In that case how would clients resolve to the needed Service Provider? ( *Main.BillBertrand* 05/24/2010) * *Response* No, a Service Provider catalog has one domain and I would infer from that that the Service Providers referenced from the catalog all implement that one domain. Please direct further questions to the mailing list, this page is for issues raised against the spec not general questions. 1 %GREEN%RESOLVED%ENDCOLOR% couple of minor grammatical issues: a) The following words are repeated (for example, _...or or...)_: or, the (two occurrences), to (two occurrences), have, of, contain, b) Change 'Open' to 'Close' in 5.3 of 'Rules for representing resources in RDF/XML'. *Resolved* Fixed all of these (DavJohnson 07/21/2010) 1 %GREEN%RESOLVED%ENDCOLOR% Attached sample representations have not kept up with changes made in the wiki, including in the main core spec, associated guidance specs, and appendices. In general, appears that even some of the examples in the wiki may have been overlooked when changes were made elsewhere in the spec. (ScottBosworth, 07/14/2010) * I went through each RDF/XML example and uploaded a new attachment for each, most were using the old representation rules, before we switched to <rdf:RDF>. I generated new Turtle examples for query shape and query result examples because the source RDF/XML changed. I also updated the Atom example to use the <rdf:RDF> form in the blog entry and comment examples. (DaveJohnson 07/21/2010). 1 %RED%OPEN%ENDCOLOR% A couple of issues in http://open-services.net/bin/view/Main/OSLCCoreSpecRDFXMLExamples: * %GREEN%RESOLVED%ENDCOLOR% Change xmlns:foaf="%RED%http://%ENDCOLOR%http://xmlns.com/foaf/0.1/" to xmlns:foaf="http://xmlns.com/foaf/0.1/". * *Response*: done! * %BLACK% %ENDCOLOR%%RED%OPEN%ENDCOLOR% Remove oslc:name property from oslc:ResourceShape since it is not supported in http://open-services.net/bin/view/Main/OSLCCoreSpecAppendixA?sortcol=table;up=#oslc_ResourceShape_Resource. * *Response*: oslc:name is part of ResourceShape * *Question:* Where is the oslc:name property defined? * %BLACK% %ENDCOLOR%%RED%OPEN%ENDCOLOR%%BLACK% %ENDCOLOR%Remove rdf:about attribute from oslc:ResponseInfo since it is not mentioned in http://open-services.net/bin/view/Main/OSLCCoreSpecAppendixRepresentations?sortcol=table;table=up#Steps_to_generate_an_RDF_XML_rep. * *Response*: rdf:about is not a property but instead a part of RDF serialization. We say that the responseInfo is "about" the current response URI and that is what we show in the example * *Question:* Can we add it to the steps? * %BLACK% %ENDCOLOR%%RED%OPEN%ENDCOLOR%%BLACK% %ENDCOLOR%The oslc:BlogQuery is not defined in the query capability of the service provider resource. * *Response*: that is correct. BlogQuery is defined in a shape and the shape is referenced from the service provider resource. * *Question:* Are you referring to #2 or #3 of http://open-services.net/bin/view/Main/OSLCCoreSpecRDFXMLExamples?sortcol=table;table=up#Specifying_the_shape_of_a_query? I am referring to #2. * Could we add an example of the oslc:score property in http://open-services.net/bin/view/Main/OSLCCoreSpecRDFXMLExamples?sortcol=table;table=up;up=#Specifying_the_shape_of_a_query? * According to the RDF, the rdf:about attribute in the oslc_blog element is invalid since '{E201} rdf:about not allowed as attribute here'. Instead, rds:description should be used. We should add a 'disclaimer' stating that the exact form of the RDF serialization does impact the struture of the RDF and rdf:/rdfs: element may differ. * Small typo 'species'. * The rdf:type property should not appear in abbreviated RDF (RDF/XML-ABBREV) XML (see http://jena.sourceforge.net/jena-faq.html#xml-1). * The rdf:type property should only contain a URI (see rdf:type=oslc_blog:Comment). See http://open-services.net/bin/view/Main/OSLCCoreSpecAppendixA?sortcol=table;up=#RDF_Properties. ---+ OSLC Defined Resources <ol> <li> CLOSED _URI Query Parameters_ - Any reason why this is limited to a mention of oslc.properties and not the whole simple query syntax? Also, the language "clients can add this query parameter to the URI of an OSLC Resource *to obtain the URI for* a resource with a subset of the resource's properties" seems a bit confusing, perhaps "clients can add this query parameter to the URI of an OSLC Resource *to obtain a representation of* a resource with a subset of the resource's properties"? (ScottBosworth, 03/03/2010) * *Response* This text has been removed from the OSLC Defined Resources section and will eventually be replaced by query syntax spec text. (DaveJohnson 03/18/2010) </li> <li> CLOSED _Common Properties - OSLC Properties_ - The specification of the oslc:preserveUnknown property was a little unexptected. Do we have clear scenarios and use cases that warrant this and that explain how this property might be made use of by service consumers and what it means for service providers? Is this property well place in the Resource Shape? If so, should it be mentioned in the Resource Shape section? (ScottBosworth, 03/03/2010) * *Response* The preserve unknown property has been removed (DaveJohnson 03/18/2010) </li> <li> CLOSED _Common Resources_ - Maybe this description is fine, but it made we wonder if, for clarity sake, we should also reflect on the use of common resources in in-line resource properties more directly? The example does this, but should the language above it include reference to OSLC Defined Properties as well as OSLC Defined Resources? Food for thought. (ScottBosworth, 03/03/2010) * *Response* Consider the new naming. Instead of Resource Links, In-Line Resources and Common Resources we now have just Nodes and Common Nodesd. (DaveJohnson 03/18/2010) </li> <li> CLOSED _Defining a Resource_ - Can string property values contain marked-up text? Some domain-specified resources have string properties whose value may include html mark-up, and other properties whose value must be simple text. Is this a Core Spec topic? Is it simply up to domain specifications to add constraints on specific string property values? (ScottBosworth, 03/04/2010) * *Response* Added an XML Literal type that can used for values that are literal XML, such as XHTML. Strings can also be used to hold marked-up content (HTML, XHTML, HTML5) but domain specs should make this clear so that clients know when to un-escape strings. (Dave Johnson 03/19/2010) </li> <li> CLOSED need to specify the XML namespace prefixes and URIs used (IanGreen, 03/03/2010) * Response The spec now explains how XML Namepaces, QName Local Names and QName Prefixes are used (<span style="color: blue; text-decoration: underline">DaveJohnson</span> 03/18/2010) </li> <li> CLOSED Defining a resource - The list of properties allowed/required should be optional. (DaveJohnson for MN, 03/16/2010) * *Response* Made it clear that listing properties is optional (DaveJohnson 03/18/2010) </li> <li> CLOSED Defining a resource - on the QName for resource: This can’t be right, because the value of RDF Type has to be a URL, not a QName. In general you cannot convert from QNames to URLs and vice versa. However, OSLC could make a local rule that its Qnames can be converted to URLs by looking up the namespace definition referenced by the first part and concatenating it with the second part. If this is what you mean, you should say so explicitly. Also, as I'm sure you know, XML [namespaces] allows the first part of a QName to be anything at all so long as it matches the a namespace definition. This means that the first part of a QName is not fixed – it can vary from document to document. The two bits you can standardize are the namespace definition and the second part of the QName. You could recommend that it’s a good practice to define a commonly-used token for the irst pat, but you can’t mandate that. (DaveJohnson for MN, 03/16/2010) * *Response* The spec now explains how XML Namepaces, QName Local Names and QName Prefixes are used (DaveJohnson 03/18/2010) </li> <li> CLOSED instead of "Resource Link" and "In-Line Resource" just call it a "Node" and allow it to be used in-line or out-of-line. (DaveJohnson for NM, 03/17/2010) * *Response* Now using Node terminology throughout document (DaveJohnson 03/18/2010) </li> <li> %GREEN%RESOLVED%ENDCOLOR% Paging: It would be good that there is a way for a OSLC Service to indicate whether Resource Paging is Unstable or Stable, so that OSLC clients can react accordingly. An indicator property in the Query Capability may be sufficient for this purpose. (TackTong, 03/29/2010) * *Response* No change. Clients should assume unstable paging unless otherwise specified, this does not need to be discoverable (DaveJohnson, 04/06/2010) </li> <li> %GREEN%RESOLVED%ENDCOLOR% This is a question not an issue. In the section Defining a Resource, what is the difference between a value-type of URI and a value-type of Node with a URI? (TackTong, 03/29/2010) * *Response* See issue #14 below, we now use three different "Resource value-types" of Resource, In-Line and Complex. (DaveJohnson, 04/06/2010) </li> <li> %GREEN%RESOLVED%ENDCOLOR% Value-types should be divided into two categories: Literals and Resources. A Literal value has a datatype URI. A Resource has an rdf:type URI. Either may be simple or complex, e.g. a Literal may be a complex XMLLiteral, and a Resource may be an inlined resource. Both Literals and Resources are nodes in the rdf graph. We discussed this today. Just adding this here for tracking. (ArthurRyman 03/29/2010) 1 Resource Value-types are now divided into either "Literal" or "Resource" value-types (DaveJohnson, 04/06/2010 </li> <li> %GREEN%RESOLVED%ENDCOLOR% For Resource Update we should ensure that two status codes are recommended: 409 for concurrency, 412 for other issues i.e. response does not include If-Match (JimConallen and PaulMcMahan, 03/30/2010) * *Response* Explained how 400, 409 and 412 should be used (DaveJohnson 04/08/2010) </li> <li> %GREEN%RESOLVED%ENDCOLOR% The value-type of “Node” is confusing and instead we should use the term Resource and perhaps three value-types: Blank Node, In-lined Resource, Resource (DaveJohnson, 03/30/2010) * *Response* Done. See issue #14 (DaveJohnson 04/06/2010) </li> <li> %GREEN%RESOLVED%ENDCOLOR% What is the value-type URI for? Is it for URI as a string? Does it indicate a “link” or a rdf:resource, rdf:about? (reporter, 03/31/2010) * *Response* (DaveJohnson 04/06/2010) This is now made clear in the spec. A URI is a literal. For a link, you would us value-type of Resource instead. We now have Resource value-types: * URI: a string that holds a URI, used for things that are not actually links to other resources, e.g. base URIs like queryURI * Complex: a property value that is a resource with property values, but has no URI, i.e. RDF Blank Node * Resource: a property value that is a resource with property values, available at specified URI * Inline: a property value that is a resource with property values, represented inline </li> <li> %ORANGE%DEFERRED%ENDCOLOR% Should we really mandate XHTML for rich text fields? What about systems that support wiki syntax or just HTML? *Response* Make common properties dc:title and dc:description XML literal with type XHTML and recommend XHTML for rich text interchange, but beyond that no mandate. Also a) The value of the dc:title property should be a single line of text, so it should be restricted to be valid content of a <span> element and b) The value of the dc:description property may be multiple lines of text, so it should be restricted to be valid content of a <div> element. %ORANGE%Once that is done in spec, mark this as deferred to ensure that we have some guidance on how to deal with text fields, rich text fields and wiki syntax%ENDCOLOR% (DaveJohnson 04/07/2010) </li> <li> <font color="blueviolet">TABLED</font> Some resources need to have ordered properties, can we introduce an ordered a value-type for “Ordered Resource” (reporter, 03/31/2010) * *Response* <font color="blueviolet" class="WYSIWYG_COLOR">Propose we table this until we have sufficient use cases</font> (DaveJohnson 04/13/2010) </li> <li> %GREEN%RESOLVED%ENDCOLOR% Instead of Resource, Inline and Complex use terminology proposed by Arthur Ryman here http://open-services.net/pipermail/oslc-core_open-services.net/2010-April/000111.html (DaveJohnson 04/12/2010) * *Response*: Yes! Get this in the spec </li> <li> %PURPLE%TABLED%ENDCOLOR% Services should specify whether each property is an extended property or not. In services that support selective properties, extended properties are only provided in resources that with oslc.properties specified. (DaveJohnson 04/12/2010) * *Response*: Added the notion of an Extended property to the OSLC Defined Resource section and a =oslc:extended= property to the Resource Shape's =oslc:Property= resource to convey this info in resource shapes (DaveJohnson 04/16/2010) * Response*: deferred this for consideration later (DaveJohnson 07/12/2010) </li> <li> %GREEN%RESOLVED%ENDCOLOR% Remove Resource Paging for resources other than query because it has not been implement, some say it is too ambitious and it places too much of a burden on existing OSLC specs that wish to migrate to the core this year (DaveJohnson 04/14/2010) * *Response*: the existing paging section has been moved into the Query Capabilties section and paging is now allowed only for Query Resources (DaveJohnson 04/16/2010) * *Reopened*: without Resource Paging for arbitrary resources we provide no way to deal with resources that have huge numbers of values for a multi-valued property (e.g. a Directory resource will millions of links to Files). Paging was always optional for providers, but if we require that clients specifically request paging (via URL parameter oslc.paging=true), then we remove the burden clients as well. Clients that don't want or know about paging will never see it and only those that want it will get it. Move paging out of query and back in to the OSLC Defined Resources section. * Resource Paging has been moved back out of the query section and into the resource section. </li> <li> %GREEN%RESOLVED%ENDCOLOR% Suggest renaming "Multi-language String" to "National Language String" See also: http://open-services.net/pipermail/oslc-core_open-services.net/2010-April/000123.html (ArthurRyman 04/19/2010) * *Response* Done. Changed in spec. (DaveJohnson 04/20/2010) </li> <li> %GREEN%RESOLVED%ENDCOLOR% The NLS string type is really unnecessary. Any string should be allowed to localized and we don't really need to talk about how this works except in the representation rules section of the spec. (DaveJohnson, 05/10/2010) * *Response* Yes, fix this as described. (DaveJohnson 05/10/2010) </li> <li> %GREEN%RESOLVED%ENDCOLOR% I am worried about the assertion that "clients should assume that an OSLC Service will discard unknown property values. An OSLC Service MAY discard property values in an OSLC Defined Resource that are not part of the resource's definition or the relevant Resource Shape." First it is impossible in the AM domain for the OSLC service specification to completely define resource definitions for all type of potentially managed resources. For example is it expected for the OSLC SCM spec to define all possible types of file resources it is allowed to version? Each service provider may specialize in one particular family of resources to manage. It is impossible and impractical to expect the OSLC to have the canonical resource definition for all UML models, etc. Each provider is expected to manage content of the types it knows about. So this means that each service provider, may have the rights to discard unknown properties, but I don't think we can elevate this to say that the OSLC is the one to define the acceptable resource propertie. (JimConallen, 05/13/2010) * *Response*: No change necessary. The rule only applies to OSLC defined resources and not opaque files (images, jars, UML diagrams) that are stored by an OSLC service. </li> <li> %GREEN%RESOLVED%ENDCOLOR% When defining a resource, do not use term "Type URI" because we are not defining a type, use URI instead. we should also point out that we are defining an RDF Class here (MartinNally via DaveJohnson 05/24/2010) </li> <li> %GREEN%RESOLVED%ENDCOLOR% When defining a property, do not use term "Type URI" because we are not defining a type, use URI instead. we should also point out that we are defining an RDF Predicate here (MartinNally via DaveJohnson 05/24/2010) * *Response* yes get this in (DaveJohnson 05/24/2010) </li> <li> <font color="forestgreen">RESOLVED</font> We have defined value-types Resource, Inline Resource, Local Resource and Local Inline Resource. Do we really truly need all of these types? We want representation to be simple and use flat name/value property model, so should we give them all these value types? Can we live without Local Resource? What about Local Inline Resource? Do we have use cases to support these things? * *Mailing list thread:* http://open-services.net/pipermail/oslc-core_open-services.net/2010-May/000269.html * *Response*: Yes, SCM and others have use cases for the local resource types, i.e. blank nodes </li> <li> %GREEN%RESOLVED%ENDCOLOR% Resource value-types (ArthurRyman, 06/14/2010) * There is a technical error in the description of Local Inline Resource and the subsequent examples. The spec incorrectly uses rdf:ID to refer to local resources. Recall that we introduced the term "local resource" to be a synonym for "blank node" because we did not want to depend on RDF terminology. I think we should look at this decision again since the new terms and descriptions we are introducing may be adding to the confusion instead of simplifying the specification. The correction is to use rdf:nodeID whenever referring to a blank node within an RDF/XML document. The rules are described in [1]. * rdf:ID is also very useful, but is not used for blank nodes. It is used to define URI references that are relative to the XML base of the RDF/XML document. [2] rdf:ID defines a unique fragment identifier within the document, which is then appended to the base URI + "#" to for a URI reference.These URI references are global, i.e. their values have meaning outside the document. They are useful for identifying resources within an RDF/XML document. * We introduced the concepts of local and inline resources to put constraints on the format of documents so that they would be easier to parse. However, we are using most of RDF/XML anyway, so maybe we should simply allow RDF/XML and use the correct RDF terms? A quick Google search shows that there are RDF parsers for all major languages. * *Response* Made correction and replaced rdf:ID with rdf:nodeID in OSLC Defined Resources section, the RDF/XML representation section, the JSON representation section and in the separate Link Guidance. On the issue of RDF terminology: can you provide RDF terminology for each of the OSLC resource value-types? On the issue of requiring an RDF parser: I think we want folks to be able to use standard XML tools. * *Response*: Split out representation from value-type. Instead of value-type we now have value-type (Resource or Local Resource) and representation (Reference on Inline). </li> <li> %GREEN%RESOLVED%ENDCOLOR% Resource: Respsonse Information - the value of oslc:nextPage should be a resource, not a string. (ArthurRyman, 06/14/2010) * *Response* changed value-type to Resource (DaveJohnson, 06/14/2010) </li> <li> %GREEN%RESOLVED%ENDCOLOR% Some have called into question the notion of extended properties. Do we really want to include them now that resource paging is back in the spec? (DaveJohnson, 06/14/2010). * *Response* We discussed this at length in the WG meeting and consensus is that we still need extended properties, but there are still concerns that it makes things more complicated for clients. Also, that inlining large binary resources as property values make not be the preferred approach. Resolution is to keep extended properties, but not emphasize them in the standard property definition table format that we use in the OSLC specs. * Response*: See above... the notion of extended properties has been tabled for later consideration (DaveJohnson 07/12/2010) </li><li>%GREEN%RESOLVED%ENDCOLOR% The oslc.where query parameter syntax is missing some properties in BNF grammar (see http://open-services.net/bin/view/Main/OSLCCoreSpecQueryDRAFT?sortcol=table;table=up;up=#oslc_where):<br />identifier ::= PrefixedName<br />PrefixedName ::= /-- see "SPARQL Query Language for RDF", http://www.w3.org/TR/rdf-sparql-query/#rPrefixedName --/ * *Response* Done (ArthurRyman, 07/27/2010) </li><li>%GREEN%RESOLVED%ENDCOLOR% The BNF grammar for uri_ref_esc is missing. It is declared in oslc.prefix (see http://open-services.net/bin/view/Main/OslcSimpleQuerySyntaxV1?sortcol=table;up=#oslc_prefix) but the 'see below' does not exist. * *Response* Added by Arthur Ryman on 07/21. </li><li>%GREEN%RESOLVED%ENDCOLOR% In the term BNF of the oslc.where query parameter syntax, the first 'space' should be 'space?' * *Response* No, the space is required in order to delimit identifiers from the "in" operator (ArthurRyman, 07/27/2010) </li><li>%GREEN%RESOLVED%ENDCOLOR% In the scoped_term BNF of the oslc.where query parameter syntax, could the identifier_wc be a wild card? * *Response* Yes, the scoped term can be a wildcard which means any property. (ArthurRyman, 07/27/2010) </li><li>%GREEN%RESOLVED%ENDCOLOR% Small typo in #2 of Member List Patterns (http://open-services.net/bin/view/Main/OSLCCoreSpecQueryDRAFT?sortcol=table;table=up;up=#Member_List_Patterns); 'oslc.searchTerm' should be 'oslc.searchTerms' (plural). * *Response* Done. (ArthurRyman, 07/27/2010) </li><li>%GREEN%RESOLVED%ENDCOLOR% The oslc.orderBy query parameter syntax is missing some properties in BNF grammar (see http://open-services.net/bin/view/Main/OSLCCoreSpecQueryDRAFT?sortcol=table;table=up;up=#oslc_orderBy):<br />identifier ::= PrefixedName * *Response* Previously added the identifier production to the oslc.where section. (ArthurRyman, 07/27/2010) </li><li>%GREEN%RESOLVED%ENDCOLOR% Consider replacing 'identifier' with 'PrefixedName' directly (see oslc.where/oslc.orderBy query parameters). * *Response* Not accepted. This saves one production but makes the BNF less semantic since !PrefixedName is used in other contexts, e.g. datatype. (ArthurRyman, 07/27/2010). </li><li>%GREEN%RESOLVED%ENDCOLOR% The oslc.searchTerms query parameter syntax has a small typo in that the comma in search_terms should be enclosed in double quotes (e.g. ","). * *Response* Done. (ArthurRyman, 07/27/2010) </li><li>%GREEN%RESOLVED%ENDCOLOR% The oslc.select query parameter syntax is missing the properties production in the BNF grammar. * *Response* Done. (ArthurRyman, 07/28/2010) </li><li>%GREEN%RESOLVED%ENDCOLOR% For oslc.properties and oslc.select query parameters, should property be replaced with identifier | wildcard in the nested_prop production? * *Response* Yes. That is an error in the BNF. It makes the rules mutually left-recusive. The correction is to replace the property term with (identifier | wildcard) as you suggest. Done. (ArthurRyman, 09/22/2010) </li></ol> ---+ Service Resources 1 CLOSED _Service Resources_ - My brain had trouble parsing the opening sentence :-) Instead of "OSLC services are available via a Service Resource which specifies the other resources that a client needs to interact with the service", how about "A Service Resource specifies the set of OSLC services (resources) that a client needs to interact with the service"? (ScottBosworth, 03/03/2010) * *Response* rewrote this text for clarity (DaveJohnson 03/18/2010) 1 CLOSED Defining a resource - a string is not the same thing as a URI in RDF. The value of the RDF type should be URI not string. (DaveJohnson for MN, 03/16/2010) * *Response* Now using URI for RDF type (DaveJohnson 03/18/2010) 1 CLOSED Defining a resource - datatype - this only makes sense for properties, but the header says resources too. (DaveJohnson for MN, 03/16/2010) * *Response* Made it clear that these are for properties only. (DaveJohnson 03/18/2010) 1 CLOSED Defining a resource - Resource Link - I don't know what this means (DaveJohnson for MN, 03/16/2010) * *Response* Comment or resolution (DaveJohnson 03/18/2010) 1 CLOSED Defining a resource - Occurs - does this whole "OSLC Defined Resources" section belong in a separate shape spec? (DaveJohnson for MN, 03/16/2010) * *Response* No change. We need a common way to define resources even those that do not have Resource Shapes* (DaveJohnson 03/18/2010) 1 CLOSED re: "those who are defining new OSLC Services are strongly discouraged from introducing new content-types. OSLC Services MUST not define new content-types. " This seems the say no and maybe. It seems hard to believe that we can predict that there will never be a case to add a new content type. Perhaps the rationale of no new content types should be given and how specs should follow that guidance. (SteveSpeicher via DaveJohnson, 03/16/2010) * *Response* Clarified language and removed redundant text, I now say SHOULD instead of MUST (DaveJohnson 03/22/2010) 1 CLOSED 8a) In "Resource Removal"....is service provider required to make this a hard or soft delete? A GET after a DELETE should result in what status code? Here's what we did for CM http://open-services.net/bin/view/Main/CmRestApiV1#Delete_a_change_request (SteveSpeicher via DaveJohnson, 03/16/2010) * *Response* The HTTP DELETE operation is already specified in HTTP and there is no need to place additional restrictions on how it is used (e.g. some OSLC domain specs and/or implementations may not actually delete the resource until some later workflow completes) 03/23/2010) 1 CLOSED 8b) In "Dublin Core Properties", it should refer to which set of DC properties these are derived (namespace), namely: The Dublin Core Metadata Terms namespace - http://purl.org/dc/terms/ Also, why is dc:creator an "In-Line Resource" and not just resource link, of which it can be inlined? What is dc:contributor used for? Can you give an example of what it would be in the context of RTC Work Item attributes? According to DC, it says "An entity responsible for making contributions to the resource." so is it implied to be what we refer to as an Owner or Assigned To? (SteveSpeicher via DaveJohnson, 03/16/2010) * *Response* a) We now refer to the DC core namespace and prefix, b) the new Node type replaces the old In-Line Resource and allows in-lining or out-of-lining (DaveJohnson 03/19/2010) 1 CLOSED 9) In "Service Resources", it would be good to have some additional information: - how service discovery works - nested service resources (SteveSpeicher via DaveJohnson, 03/16/2010) * *Response* Added oslc:serviceContext property, added note about how services can be nested and updated the RDF/XML representation example to show nested oslc:Services (DaveJohnson 03/23/2010) 1 _Since oslc:properties can be used with a Resource URI, where do I find the Resource Shape Resource associated with the Resource for constructing the query using oslc:properties. Do I assume the oslc:shapeURI in the Creation Capability of that Resource is the one to use? (TackTong, 03/19/2001)_ * *Response* Yes, that is correct. (DaveJohnson 03/23/2010) 1 CLOSED _Query Capability - It states that oslc:shapeURI (URI, zero-or-many). Like to understand the use case for many Resource Shape Resource for a single Query Resource. How do I determine which one to use or in fact, they are cumulative? (TackTong, 03/19/2001)_ * *Response* If an OSLC domain spec has specified multiple shapeURI values then the domain spec should also explain which ones should be used for which purposes. (DaveJohnson 03/23/2010) * *Response* The intention of Service Provider Resource is for a Client to discover the Services and Capabilities provided. It would defeat the purpose if one has to look up the OSLC Domain spec. to find out which URI is for what purpose. In fact, a Query URI is an implementation URI. I am not sure it would be in OSLC Domain spec. Also, there are definitely could be Service Provider extended Query URI that are not in OSLC Domain Spec. (TackTong, 03/29/2010) * *Response*: consensus from the Core spec review was that adding a multi-valued oslc:memberProperty to Query Capability would resolve this issue because it would allow a client to determine which query capability to use for different collections of resources (<span style="color: blue; text-decoration: underline">DaveJohnson</span> 04/07/2010) 1 CLOSED Node: Query Capability : oslc:shapeURI (URI, zero-or-many): Query Capability MAY provide Resource Shapes that describe the resources that can be created by the capability. This is probably a cut and paste error. Should be ...... can be queried by ...... (TackTong, 03/29/2010) * *Response* fixed the typo (<span style="color: blue; text-decoration: underline">DaveJohnson</span> 04/07/2010) 1 CLOSED A Query Capability may have many oslc:shapeURI and each Resource Shape that those oslc:shapeURI point to are describing a Resource. There needs to be some indication or description about each of the oslc:shapeURI properties on what are the Resources they are describing. (TackTong, 03/29/2010) * *Response* Added an oslc:defines (URI, exactly-one) to the Resource Shape resource so that clients can determine which resource is defined by each shaoe 1 CLOSED It states that one of the property of a Query Resource is "rdf:type (URI, exactly-one): a Query Resource MUST include one rdf:type property with value of http://open-services.net/xmlns/oslc#Query and MAY include other instances of the rdf:type property with other values." not sure what is the use case for having more than one rdf:type for a Query Resource? (TackTong, 03/29/2010) * *Response* We now have exactly-one (<span style="color: blue; text-decoration: underline">DaveJohnson</span> 04/07/2010) 1 %GREEN%RESOLVED%ENDCOLOR% ‘oslc:creationURI’ (URI, only-one) - the URI of the creation factory. Is this a sort of "self" reference? If so, why do we need it? Or does the creationFactory (which has a URL) points to yet another URL that I use for POST? Hopefully not, because then I'd want to know more about this other URL - for example what properties does it have and what happens when I do GET on it? (DaveJohnson for MN, 03/31/2010) * *Response* We now use the value-type "URI" which means "<span style="font-family: arial,verdana,sans-serif; font-size: 14px; line-height: 20px" class="Apple-style-span">a string representation of URI, not intended to be a link but could be a base for forming other URIs</span>" and we describe the creationURI as "to create a new resource via the factory, post it to this URI" DaveJohnson 04/xx/2010) 1 %GREEN%RESOLVED%ENDCOLOR% >> oslc:queryURI (URI, only-one): query URI that serves as base URI for forming Query Resource URIs. Is this really a URI? If it's a URI, then it's the URI of some resource that presumably wee need to describe. If there is no such resource to describe, we shouldn't call this a URI,we should just call it a "root" or something (reporter, 03/31/2010) * *Response* We have renamed the queryURI as baseURI and describe it as "the base to use for forming query URIs" (DaveJohnson 04/xx/2010) 1 %GREEN%RESOLVED%ENDCOLOR% Service Provider example does not reflect Steve’s original example, which had a service provider example had a reporting service, provider supporting 2 services (DaveJohnson, 03/31/2010) * *Response* Changed so that the service provider now shows a CM service (example-cm) and a Reporting service (example-reporting), named so they are not confused with real specs (DaveJohnson 04/07/2010) 1 %GREEN%RESOLVED%ENDCOLOR% Ensure that there's a way to get from resource back to its service provider. oslc:context points to service? oslc:serviceProvider points to provider? (DaveJohnson, 03/31/2010) * *Response* The oslc:scope (formerly known as oslc:context) is defined as "<span style="font-family: arial,verdana,sans-serif; font-size: 14px; border-collapse: collapse; line-height: 20px" class="Apple-style-span">The scope of a resource is a link to the resource's <span style="border-width: 0px 0px 1px; border-color: #dddddd; border-style: solid" class="twikiNewLink">ServiceProvider</span></span>" (DaveJohnson 04/xx/2010) 1 %GREEN%RESOLVED%ENDCOLOR% re: Service Resources. domainNamespaceUI is really rdf:type, why not simply use that? (DaveJohnson, 03/31/2010) * *Response* rdf:type is for indicating a resource's type and what we want here is to identify the OSLC domain that is implemenbted by service, I think the name oslc:domain is suitable and that is what is now in the spec. (DaveJohnson 04/07/2010) 1 CLOSED Need to fold in and align how OslcServiceProviderCatalogV1 works with Service Resource (SteveSpeicher, 03/31/2010) * *Response* Will continue to have an optional Service Provider Catalog that can be nested. Spec has been updated to include this resource now (SteveSpeicher 04/17/2010) 1 %GREEN%RESOLVED%ENDCOLOR% Need predefined namespaces (defined at the service provider level) so that they need not be specified in the Query Syntax URI which results in longer and uglier URLs (ArthurRyman, 03/31/2010) * *Response* We now required Service Providers to define, in their Service Provider doc, all namespace prefixes that they introduce. This is done by the introduction of a NamespaceDefinition resource and the addition of a multi-valued namespaceDefintion property to the ServiceProvider resource definition. Also, changed the JSON representation rules to use the NamespaceDefinition concept they way to declare namespaces. DaveJohnson 04/15/2010) 1 %GREEN%RESOLVED%ENDCOLOR% Need a way for a Resource Shape to indicate which properties are to be shown/allowed to be editing in a UI (DaveJohnson, 04/14/2010) * *Response* Now oslc:Property resources can include an oslc:hidden value to hint that the property may be hidden in a UI (DaveJohnson 04/16/2010). 1 %GREEN%RESOLVED%ENDCOLOR% In the Query Capability: baseURI and shapeURI should be resources not URIs and should be named 'queryBase' and 'shape' (DaveJohnson, 04/19/2010) * *Response* Yes. This is now reflected in the spec. (DaveJohnson 04/19/2010). 1 %GREEN%RESOLVED%ENDCOLOR% In the oslc:Property: namespace and valueType not be a URIs, it should be a resource (<span style="color: blue; text-decoration: underline">DaveJohnson</span>, 04/19/2010) * *Response* Yes. This is now reflected in the spec. (<span style="color: blue; text-decoration: underline">DaveJohnson</span> 04/19/2010). 1 <font color="forestgreen" class="WYSIWYG_COLOR">RESOLVED</font> dc:contributor in ServiceProvider definition may not be right (SteveSpeicher, 05/12/2010) * *Response* dc:publisher is probably a better fit. Should rename resource type from Contributor to Publisher perhaps as well (SteveSpeicher 05/12/2010) * *Response*: switched to dc:publisher (DaveJohnson 05/19/2010) 1 %GREEN%RESOLVED%ENDCOLOR% In the ServiceProvider resource, do not use term Namespace Definition because we not defining namespaces, we are defining prefixes. Use classname "PrefixDefinition" with properties "prefix" and "prefixBase" (MartinNally via DaveJohnson 05/24/2010) * *Response* yes get this in (DaveJohnson 05/24/2010) 1 %GREEN%RESOLVED%ENDCOLOR% In Conceptual Model diagram oslc:QueryCapability should be oslc:queryCapability - the convention is that property names start with lowercase letter, and class and individual names start with uppercase letter. (ArthurRyman, 06/14/2010) * *Response* Fixed in diagrams 1 %GREEN%RESOLVED%ENDCOLOR% Namespace Definition versus Prefix Definition - I think these are the same thing, but both terms are used in the spec. We should use PrefixDefinition. (ArthurRyman, 06/14/2010) * *Response*: Concur. Replaced references to NamespaceDefinition with Prefix definition. 1 %GREEN%RESOLVED%ENDCOLOR% Resource: Service Provider - the spec says that namespace definitions, aka predefined prefixes, can be used in JSON respresentations, We should only use predefined prefixes on URLs to keep them short and readable. We should NOT use predefined prefixes in documents. Documents should be self-contained and define any prefixes they use.(ArthurRyman, 06/14/2010) * *Response*: Concur and removed text "and that JSON Representations *MUST* use in all property names" 1 %GREEN%RESOLVED%ENDCOLOR% Resource: Creation Factory - the spec uses both oslc:Factory and oslc:CreationFactory. These are the same. We should only use oslc:CreationFactory (ArthurRyman, 06/14/2010) * *Response*: Concur and we now use only oslc:CreationFactory. 1 %GREEN%RESOLVED%ENDCOLOR% Conceptual Model: the figures illustrating service resources and properties look out of date when compared to the tables that follow (e.g. contributor/publisher in Service Catalog, plus several others). (ScottBosworth, 07/16/2010) * *Response*: Did a close review of the diagram and made corrections (DaveJohnson 07/21/2010) ---+ Creation Resources 1 CLOSED Creating an OSLC Defined Resource - what is special below? what is special below? Other than the fact that the representations are governed by OSLC workgroups, this looks totally "vanilla" HTTP (DaveJohnson for MN, 03/16/2010) * *Response* Reworded to avoid giving impression that we have a bunch of special rules about OSLC Defined Resource, for the most part they are just resources (DaveJohnson 03/19/2010) 1 CLOSED Unknown properties - preserveUnknown cannot go in shape, should go in service or factory or somewhere else. (DaveJohnson for MN, 03/16/2010) * *Response* Removed preserveUnknown from the spec (DaveJohnson 03/19/2010) 1 CLOSED 10) In "Creation Resources", it would be useful to identify what HTTP status codes one would get back and why : missing required fields, etc....See http://open-services.net/bin/view/Main/CmRestApiV1#Create_a_new_change_request * *Response* HTTP error code and their meanings are already specified in HTTP and there is no need to repeat them here. This type of information should be included in a implementors guide or other informative documentation (Dave Johnson 03/23/2010) 1 CLOSED 11) In sub-section "unknown properties and content", would it not be more appropriate for the service provider to reject the request if it receives unknown content. It seems odd that a client would be under the impression it is sending properties, server says it create resource and client can't locate those properties. I guess I don't understand what use case this is trying to solve, seems like it adds ambiguity to the service. * *Response* Remove preserveUnknown, but we are sticking to the "may discard unknown content" rule. In my opinion, that does not preclude services from rejecting a post with unknown properties. (DaveJohnson of resolver 03/19/2010) 1 %GREEN%RESOLVED%ENDCOLOR% How does a client programmatically determine which creation factory to use to create a resource of a specific type? See the thread linked below (DaveJohnson 6/1/2010). * [http://open-services.net/pipermail/oslc-core_open-services.net/2010-May/000281.html] * [http://open-services.net/pipermail/oslc-core_open-services.net/2010-June/000282.html] * *Reponse*: design mechanism for identifying services so that clients can ask for them by ID instead of navigating Resource Shapes, etc. Here's one proposal that we accepted and implemented in the Core spec: * http://open-services.net/pipermail/oslc-core_open-services.net/2010-June/000313.html ---+ Query Capabilities 1 CLOSED Query Resources - intro paragraph not well explained (DaveJohnson for MN, 03/16/2010) * *Response* We now use Query Capability terminology and avoid the Query Resource vs. Query Resource URI confusion (DaveJohnson 03/25/2010) 1 CLOSED Resource Query - What seems tome to be important is to say that query results may take 2 diferent forms 1) an RDF list 2) an RDF graph. This is the most important part of the "conceptual model" for clients, and it’s missing here. (DaveJohnson for MN, 03/16/2010) * *Response* No change. We need to specify in OSLC Core terminology what a query resource looks like, and we will, but we will not use the terms RDF list or RDF graph. We will have only one shape for query results. (Dave Johnson 03/23/2010) 1 CLOSED Forming a Resource Query URI - One thing that is confusing here is whether the query resource is itself a query. I would suggest it should not be – the query resource should return information on how to use query for this service. It might for example return information on the query parameters it supports, and the resource shapes that can be used in queries. (DaveJohnson for MN, 03/16/2010) * *Response* No change. We will not specify what happens on HTTP GET of a Query Capabilities base URI because some OSLC domains and/or implementations might want AtomPub collection-like behavior (e.g. post to URI to create and get on that same URI to get collection) (DaveJohnson 03/23/2010) 1 CLOSED Query Resource - The words "list of links" is unclear, please clarify or define the term Link in the glossary (SteveSpeicher via DaveJohnson, 03/16/2010) * *Response* Rewrote to remove those words (DaveJohnson 03/23/2010) 1 CLOSED For "URI Query Parameters", this should also include "oslc.prefix" to <span style="font-style: italic" class="Apple-style-span">allow for defining namespace prefixes (</span><span style="font-style: italic" class="Apple-style-span">SteveSpeicher</span><span style="font-style: italic" class="Apple-style-span"> via </span><span style="font-style: italic" class="Apple-style-span">DaveJohnson</span><span style="font-style: italic" class="Apple-style-span">, 03/16/2010) </span> * <span style="font-weight: normal" class="Apple-style-span"> *Response* </span>Will be addressed in Query Syntax section (DaveJohnson 03/23/2010) 1 CLOSED 12) General comment, not limited to Query's usage of dc:title, is representing alternative translations and how they'd be represented. For example, Accept-Language on requests and Content-Language on response. * *Response* See same issue in Resource Shapes section below (DaveJohnson 03/23/2010) 1 CLOSED) In section "Forming a Query Resource URI", it is not clear what the first paragraph is saying. I think some of what it is saying is what we put in the CM spec: If this parameter (oslc.query) is omitted, the server MAY respond with: * a page of results * reject the request with a HTTP response code of 403 Forbidden. * all results * *Response* Don't think this comment applies any more, text has been removed (DaveJohnson 03/26/2010) 1 %GREEN%RESOLVED%ENDCOLOR% Suggest to explicitly specify what properties would be returned if oslc.properties is omitted. There has been numerous discussions and speculations. Having it clearly specified in the doc. would clarify once for all. (TackTong, 03/19/2010) * *Response* We now the notion of Extended Properties that only appear in resources when specified by oslc.properties in the resource URI (DaveJohnson 03/26/2010) 1 CLOSED The conceptual model in the Query Resource section does not clearly state how a query result would be represented in the data model. So far, it only states that Query Resource has properties rdf:type and dc:title. Need to describe a data model of how a Query Resource would be resulted from a query of a collection of resources of the same type. In additional, an example of a conceptual model of Query Resource, a query, and its resultset plus applying the RDF/XML representation rule to arrive at a RDF/XML representation of the resulted Query Resource would be greatly helpful. (TackTong, 03/19/2010) * *Response* We now specify a Query Resource in OSLC Defined Resource terminology and have specific rules for how it is represented (03/26/2010) 1 CLOSED Suggest stating a design point for Query such that the Resource Shape of the resulted Query Resource from a query is determinable from the query itself and the Resource Shape Resource associated with the original Query Resource. Reporting has a strong dependency on this design point for Query. (TackTong, 03/19/2010) * *Response* Query Capability now has a query URI and a set of Resource Shapes (DaveJohnson 03/26/2010) 1 %GREEN%RESOLVED%ENDCOLOR% queries should support POST as well; useful when query is very long (IanGreen, 03/03/2010) * *Response* Done. This is now in spec (DaveJohnson 03/xx/2010) 1 %GREEN%RESOLVED%ENDCOLOR% "the base URL is additionally viewed as having an associated set other resources. The members of this associated set are objects of one or more membership properties. The oslc.from query parameter lets you specify which subset of membership properties to use. " So, looks like the member property is associated with a Query Capability, not a Resource. Thus, need to add oslc:memberProperty to Query Capability. In this case, is oslc:memberProperty still valid for a Resource and defined in Resource Shape? I believe yes for multi-value properties. But like to confirm. (TackTong, 03/29/2010) * *Response* No, membership properties are like other multi-valued properties of a resource. They simply have the additional semantics that they define a set of members. They should be defined in the Resource Shape. The query parameters can be appended to any resource, not just Query Capability resources. A Query Capability resource is more like an entire RDF graph instead of a subject node that belongs to the graph. * *Response* (ArthurRyman 04/07/2010). I will improve the text of the Query Syntax section to clarify this. (ArthurRyman 04/20/2010) I clarified this by using the terms self-subject and multi-subject to describe Query Capabilities - this is represented by the oslc:isMultiSubject property. We no longer need oslc:memberProperty in Query Capability. We should find the membership properties by looking at the oslc:isMemberProperty property in oslc:Property in oslc:ResourceShape. *DONE*. (ArthurRyman 04/22/2010) oslc:memberProperty removed from spec. 1 %GREEN%RESOLVED%ENDCOLOR% oslc.prefix : "An OSLC service SHOULD predefine namespace prefixes for its properties. " Where would the predefined namespace prefixes be discovered? Are they in Service Provider Resource? (TackTong, 03/29/2010) * *Response* I think the predefined prefixes should be global to the entire service, i.e. we would not want the same prefix to mean different things on different URLs. The Service resource seems like the right place to define them. (ArthurRyman 04/07/2010) 1 %GREEN%RESOLVED%ENDCOLOR% Data types in oslc.where parameter : It is not clear from an implementers point of view how to parse some values in the where clause. Take as an (unencoded) example: =oslc.where=foo:bar="pathmap:/folder1/data.dat"=. When I try to map this to a SPARQL query should I interpret the value as a string or a URI? Given in some applications there may be 100s of different resource shapes that could be matched, many of which have a foo:bar property (some using string values and some URIs), the query parser just doens't have enough information to know which way to interpret it. The argument is similar for knowing the different between boolean/text and decimal/text. etc. (JimConallen, 03/30/2010) * *Response* We discussed this on a call and we agreed on a couple of points. First, we should use angle brackets instead of double quotes to distinguish URIs from strings. Second, we should allow the standard RDF syntax of appending a datatype to a literal value, but not require this. The Simple Query Syntax is supposed to be simple, i.e. easy to write. Since we have Resource Shape information, the query parser should be able to infer the datatype of a property in most cases. However, there are cases when more than one datatype is permitted. The literal value should include a datatype in order to distinguish which datatype is intended. So datatypes are permitted but not required, and a parser should use the Resource Shape or some other information to infer the datatype. If the datatype cannot be inferred, then the service can select an appropriate behavior, e.g. return an error or make a guess. I will update the Query Syntax. (ArthurRyman 04/07/2010). * *Response* I updated the specs to use angle brackets for URIs and to allow both plain literals and typed literals. The syntax for literals allows for URI (delimited by angle brackets), string (delimited by double quotes), decimal (numeric), and boolean (true or false) values, optionally followed by the string "^^" and the prefixed name of a datatype. (ArthurRyman, 04/10/2010). 1 %GREEN%RESOLVED%ENDCOLOR% !DateTime format oslc.where parameter : Should we standardize the date time format? For example what is this date: "01/02/2010". Perhaps if we require explicit data types (to solve the above problem) we can expect to see date time values like: =oslc.where=dc:created>"2009-10-20T19:49:47Z"^^xsd:dateTime= (JimConallen, 03/30/2010) * *Response* See above. We should use the standard XSD datatypes since that aligns with RDF and SPARQL. We should standardize on xsd: as the predefined prefix for XSD. For dates, the ^^xsd:dataTime suffix is permitted, but optional, which is consistent with type inference as described in the preceeding issue. I will update the Query Syntax section. (ArthurRyman 04/07/2010). * *Response* Done. (ArthurRyman 04/10/2010). 1 %GREEN%RESOLVED%ENDCOLOR% Can BNF for =oslc.where= parameter explicitly allow wildcard (*) for property identifier. This will enable us to query for all resources that have any link to a given URI. This idea was suggested by Arthur offline earlier. (JimConallen, 03/30/2010) * *Response* Yes, a wildcard for the property name in the =oslc.where= clause should not cause any difficulty. I will update the Query Syntax section. (ArthurRyman, 04/07/2010). * *Response* I updated the spec. The syntax for =oslc.where= now uses the term identifier_wc which is either an identifier or a wildcard. (ArthurRyman, 04/13/2010). 1 %GREEN%RESOLVED%ENDCOLOR% There may be one or more Membership Property that defines the members of a collection. This arose in review with MN and the Query Syntax was enhanced with the =oslc.from= parameter to support this scenario (ArthurRyman, 03/29/2010) * *Response* I added =oslc.from= to the Query Syntax. (ArthurRyman, 04/07/2010) 1 %GREEN%RESOLVED%ENDCOLOR% In Query Syntax, state that the query parameters may be appended to a Query URI or to a plain old resource URI. (ArthurRyman, 03/29/2010) * *Response* I edited the spec. (ArthurRyman, 04/20/2010) *DONE* 1 %GREEN%RESOLVED%ENDCOLOR% Don't return 403 when properties specified in URI via =oslc.properties= are not found... (reporter, 03/31/2010) * *Response* AI: for Arthur: Remove link to old documents that reference this (DaveJohnson 04/xx/2010) * *Response* (ArthurRyman, 04/20/2010) *DONE* 1 %GREEN%RESOLVED%ENDCOLOR% The sections on =oslc.properties= and =oslc.prefix= link out to a separate OSLC specification "OSLC Syntax for Property Selection and Namespace Prefixes" -- this link should be removed and any specification text needed moved into the Core spec. (DaveJohnson 04/12/2010) * *Response* (ArthurRyman, 04/20/2010) *DONE* 1 %GREEN%RESOLVED%ENDCOLOR% The original intention for oslc:Query was that it should represent the results of a query. However, we don't use it for that purpose. We now use rdf:RDF for multiple subjects or a node element for the resource type as the document roots in RDF/XML. We do use oslc:Query to convey paging information via the oslc:nextPage property. However, we might need to page any resource, not just the result of a query. Therefore, this resource should become a blank node of type, e.g. oslc:ResponseInfo, because it really tells us information about an HTTP response. We can then use it in any HTTP response to indicate paging and potentially other properties that are about the response. (ArthurRyman, 04/20/2010) * *Response* (ArthurRyman, 04/22/2010) Updated spec is use the name oslc:ResponseInfo. *DONE* 1 <font color="limegreen" class="WYSIWYG_COLOR">RESOLVED</font> Query simplifications. The new query parameters that we have added into the OSLC Query Syntax and useful and well thought out, but they go well beyond what we have in the v1 specifications. We can ease OSLC Core spec adoption and migration by simplifying the query syntax and removing the oslc.from, oslc.offset, oslc.limit and oslc.properties -- oslc.properties should be moved out of the Query Syntax and back into the OSLC Defined Resources section. (DaveJohnson, 05/10/2010) * *Response* * Query Resource Paging moved to OSLC Defined Resources section, called Resource Paging again * oslc.properties, oslc.prefix and oslc:ResponseInfo all moved out of query and into Core spec proper * oslc.from and oslc:memberProperty deferred to later version of query syntax * Created new OSLC Core Query Syntax v.Next by copying current query spec, before removing oslc.from, etc. * (DaveJohnson 05/25/2010) 1 %GREEN%RESOLVED%ENDCOLOR% Resource Shapes are supposed to be optional and not required for query, so oslc:shape should be zero-or-one not exactly-one (DaveJohnson 05/18/2010) * Response Corrected in spec (DaveJohnson 05/18/2010) 1 %GREEN%RESOLVED%ENDCOLOR% How does client know which property's values are the query results. Is it good enough to let client assume that all property values other than oslc:reponseInfo are query results? * Initial response: As things stand today OSLC domain specs will have to specify the data model for their query resources. They can use OSLC defined resources terminology or a shape to do this, but the result could be a different query representation for each domain. I think this is a problem and my preferred solution to this is to define a simple query shape in Appendix A, make it optional and encourage OSLC domains to use it rather than defining new query data models and representations. (DaveJohnson 05/27/2010) * *Mailing list thread:* http://open-services.net/pipermail/oslc-core_open-services.net/2010-May/000260.html * *Reponse*: No action, do not add query resource definition. Consensus seems to be that there is no need to specify a Query Resource format because 1) the format of a query result is specified via query syntax and 2) query capabilities that do not use query syntax will have to specify something non-standard and that is acceptable (DaveJohnson 06/28/2010) ---+ Resource Shape Resources 1 CLOSED worried that Resource Shape notion is too brittle/inflexible, do we really want it in core? (IanGreen, 03/03/2010) * *Response* No Change. We need resource shapes in core, however we have taken steps to keep them from being typed to types and used as a rigid constraint or schema system (Dave Johnson 03/19/2010) 1 CLOSED Consider moving Resource Shapes to an independent spec (DaveJohnson for MN, 03/16/2010) * *Response* No Change. We need resource shapes in core. (Dave Johnson 03/19/2010) 1 CLOSED 15) For Property "oslc:preserveUnknown", is the default value "false"? Since it is "at-most-one", it implies its optional. (SteveSpeicher via DaveJohnson, 03/16/2010) * *Response* Removed the oslc:preserveUnknown property (DaveJohnson 03/23/2010) 1 CLOSED 16) There is no definition of what "olsc:when" is used for. Likewise, it is unclear the purpose of "oslc:RdfTypeTest" (SteveSpeicher via DaveJohnson, 03/16/2010) * *Response* Removed the oslc:when element (DaveJohnsoin 03/23/2010) 1 CLOSED 17) For "Resource: Property" there should be default values for some of these: oslc:readOnly, oslc:maxSize?, oslc:occurs (SteveSpeicher via DaveJohnson, 03/16/2010) * *Response* Added clarification for oslc:readOnly and oslc:maxSize. No default is needed for oslc:occurs as it is required. (DaveJohnson 03/23/2010) 1 CLOSED instead of all this oslc:test and oslc:when stuff, allow each Node to point to it's Resource Shape (DaveJohnson for NM, 03/17/2010) * *Response* Nodes can now point to their shape (DaveJohnson 03/23/2010) 1 CLOSED "An OSLC Service MAY define one or more Resource Shapes for each RDF Type of resource that it defines. " The latest discussion was a Resource Shape Resource for all resources within the RDF graph that the service manages. Is this a change in direction? Like to understand whether this is a change and the rationale behind it. (TackTong, 03/19/2010) * *Response* That text has been removed from the spec. See the overview for the relationship between service, creation capability, query capability and resource shape (DaveJohnson 03/23/2010) 1 CLOSED In OSLC Query Simple Syntax V1, it states in the section "Describing Collections and Member Properties", "The above discussion assumes that the author of the query knows which resources are collections and which properties of those resources are membership properties. The service must specify that information by some mechanism. " Thus, in Query there is a notion of member property in a collection. I was assuming that the Resource Shape Resource will be the mechanism to specify that information. Thus, I like to suggest adding a property to the Resource Shape Resource to indicate which one is the member property of a collection resource. May be something like oslc:memberProperty which is a boolean True or False. (TackTong, 03/19/2010) * *Response* Comment or resolution (DaveJohnson 03/26/2010) 1 CLOSED If the property has oslc:valueType = URI or NODE, the client needs to know the type of the URI or NODE it points to, so that it can look at the Resource Shape Resource for that type to construct query for embedded inline properties in the Query result. We need another property to indicate this in the Resource Shape Resource. (TackTong, 03/19/2010) * *Response* Yes. The oslc:nodeShape property was in the wrong place. Within a Resource Shape, each oslc:Property with value0-type Node can now specify the oslc:nodeShape URI of the Resource Shape that applies to the Node (DaveJohnson 03/23/2010) 1 %GREEN%RESOLVED%ENDCOLOR% "A Resource Shape describes the properties that are allowed or required by one type of Node or Resource." But in Resource: Resource Shape, it does not have any property to indicate which resource type it is describing. Thus, suggest to add a property oslc:resourceType or oslc:nodetype for this purpose. (TackTong, 03/29/2010) * *Response* Added oslc:decribes so that a shape can indicate the Type URI that it is describing. (DaveJohnson 04/08/2010) 1 %GREEN%RESOLVED%ENDCOLOR% A oslc:valueType of URI in oslc:property may mean it is an URI to a resource. e.g. A TestPlan may have URI to TestCase(s). In order to construct a query to get back TestPlan embeded with TestCase(s). The client needs to know the shape of the resource the URI points to (TestCase, in this example). Thus, suggest oslc: nodeShape applies to oslc:valueType of URI property as well. (TackTong, 03/29/2010) * *Response* Shapes are allowed for all Resource value types but not for value-type URI which is a literal string representation of a URI 1 %GREEN%RESOLVED%ENDCOLOR% In Resource Shape, why is the property oslc:properties plural? Doesn't it define a single property. The property is multi-valued but each one refers to a single oslc:Property node. (ArthurRyman 03/29/2010) * *Response*: good point, this has been renamed (DaveJohnson 04/08/2010) 1 %GREEN%RESOLVED%ENDCOLOR% In Property, it is not technically correct in the RDF data model to define the name of the Property to be a pair of oslc:name and oslc:namespace. Instead, the Property name is a single URI. The split into two parts is done for abbreviation via !PrefixedName. (ArthurRyman 03/29/2010) * *Response*: rewrote many parts of spec to use new Prefixed Name terminology (DaveJohnson 04/07/2010) 1 %GREEN%RESOLVED%ENDCOLOR% It states that one of the property of a Resource Shape is " rdf:type (URI, exactly-one): a Query Resource MUST include one rdf:type property with value of http://open-services.net/xmlns/oslc#Shape and MAY include other instances of the rdf:type property with other values. " I believe this is a cut and paste error. It should not be "a Query Resource MUST.....". However, not sure what is the use case for having more than one rdf:type for the Resource Shape?(TackTong 03/29/2010) * *Response*: only allow on now (<span style="color: blue; text-decoration: underline">DaveJohnson</span> 04/07/2010) 1 %GREEN%RESOLVED%ENDCOLOR% re: Node properties MAY provide oslc:nodeShape, not SHOULD (DaveJohnson for MN, 03/31/2010) * *Response* Yes get this in the spec (DaveJohnson 04/xx/2010) 1 %GREEN%RESOLVED%ENDCOLOR% Explain specifically what oslc:memberProperty means, the curent definition is not sufficient, uses undefined terms (DaveJohnson for MN 03/31/2010) * *Response* Moved to Service Resources and defined a little better (DaveJohnson 04/xx/2010) 1 %GREEN%RESOLVED%ENDCOLOR% A Resource Shape should define what rdf:type that it is defining. (DaveJohnson, 03/31/2010) * *Response* added oslc:defines (DaveJohnson 04/xx/2010) 1 %GREEN%RESOLVED%ENDCOLOR% If a provider wants to provide multiple labels for a property (one for each lang supported), it would seem natural to have an additional dc:title with a different xml:lang attribute, though that property has the constraint of no-more-than-one. (<span style="color: blue; text-decoration: underline">SteveSpeicher</span>, 04/07/2010) * See also Arthur's comment [[http://open-services.net/pipermail/oslc-core_open-services.net/2010-April/000118.html][open-services.net/pipermail/oslc-core_open-services.net/2010-April/000118.html]] * See also Arthur's comment [[http://open-services.net/pipermail/oslc-core_open-services.net/2010-April/000119.html][open-services.net/pipermail/oslc-core_open-services.net/2010-April/000119.html]] * *Response* Added a new value-type called Multi-language string, which is based on XSD string and where each value is expected to convey one language version of the string. In JSON representations, we represent this with an object with field-names that correspond to language codes. In RDF/XML representations, we use the =xml:lang= attribute (DaveJohnson 04/xx/2010) 1 %GREEN%RESOLVED%ENDCOLOR% Resource Shape value types are wrong and do not match those in the OSLC Defined Resources section (DaveJohnson, 05/10/2010) * *Response* Review and ensure the lists match 100% type for type (DaveJohnson 05/10/2010) 1 %GREEN%RESOLVED%ENDCOLOR% Resource Shape Property's defaultValue property should be the same value-type as the property with which it is associated (DaveJohnson, 05/10/2010) * *Response* Yes, fix this as described. (DaveJohnson 05/10/2010) 1 %GREEN%RESOLVED%ENDCOLOR% Resource Shape Properties allowedValues property needs work. It should be either a resource or an inline resource, and should provide a min/max range for number and date value types. (DaveJohnson, 05/10/2010) * *Response* Yes, fix this as described. (DaveJohnson 05/10/2010) 1 %GREEN%RESOLVED%ENDCOLOR% Resource Shapes are really just a common resource and we should not place such a big emphasis on them by making them a major heading in the core spec. Instead, move them to Appendix A as a type of Common Resource (DaveJohnson, 05/10/2010) * *Response* Done. Correction made (DaveJohnson 05/18/2010) 1 %GREEN%RESOLVED%ENDCOLOR% Ian Green posted an issue on the OSLC Core Mailing list: http://open-services.net/pipermail/oslc-core_open-services.net/2010-May/000250.html. The gist of Ian's comment is that we should use rdf:predicate within a property definition to specify the predicate that we are defining. Arthur Ryman responded that rdf:predicate is inappropriate (IanGreen via DaveJohnson 05/25/2010). * *Response*: Use =oslc:propertyDefinition=, a name which makes it clear that a shape does not define properties. Properties are defined else where and a shape describes how they are to be used in OSLC. (DaveJohnson 06/1/2010). 1 %GREEN%RESOLVED%ENDCOLOR% How does a service make resource shapes available for its resource, common and customized? Do we host resource shape representations at open-services.net? Do we expect implementations to provide them? (Dave Johnson 6/1/2010) * *Response*: added some text to the Common Properties section in Resource Shapes: * _OSLC implementations that provide Resource Shapes representing resources defined by OSLC specifications are expected to provide the very same information provided in the specifications without changing or removing any of the Properties specified. Resource Shapes *MAY* include new implementation specific properties as long as such "custom" properties are defined in non-OSLC namespaces (i.e. not rooted at http://open-services.net)._ 1 %GREEN%RESOLVED%ENDCOLOR% We do not want to enable rigid schemas and we're not convinced that Resource Shapes are useful beyond Resource Creation, Query and possibly a constrained form of query. So, we should not tie shapes to types and the =oslc:describes= property should be removed from the =oslc:ResourceShape= class (DaveJohnson on behalf of Martin Nally, 06/14/2010). * *Response* No action: do not remove. Consensus is that this is a useful property and is now required by use cases in the Estimation and Measurement spec (DaveJohnson 06/28/2010) 1 %GREEN%RESOLVED%ENDCOLOR% Value-type: Property. The property rdf:predicate is not appropriate since RDFS semantics imply that its subject is an rdf:Statement, which is not what we intend here.<br />Suggest using oslc:onProperty since it is similar to owl:onProperty * *Response*: Concur and made recommended change. 1 %GREEN%RESOLVED%ENDCOLOR%Value-type: Property. S hould explain the meaning of oslc:valueType to be the union of all the value types mentioned. The design of this property is inconsistent since for literal value types we can specify the datatype but for URI-valued properties we cannot specify the type, just how they are represented (inline, local, etc.) * *Response*: Concur and made recommended change. 1 %GREEN%RESOLVED%ENDCOLOR% The namespace for the Resource value-types includes "oslc-core" but the normal core namespace just includes "oslc", not "oslc-core". Use just one<br />base URI for all URI refs in the core. * *Response*: Concur and made recommended change. 1 %GREEN%RESOLVED%ENDCOLOR% The datatype of oslc:maxSize is Number which is not a datatype. Use Integer. * *Response*: Concur and made recommended change. 1 %RED%OPEN%ENDCOLOR% Small typo for the OSLC namespace in the resource value-types in http://open-services.net/bin/view/Main/OSLCCoreSpecAppendixA#oslc_ResourceShape_Resource. Change http://open-service.net/ns/core# to http://open-service%RED%s%ENDCOLOR%.net/ns/core#. ---+ Delegated User Interface 1 CLOSED Delegated UI section needs some work to bring it in line with the Core spec terminology. (<span style="color: blue; text-decoration: underline">DaveJohnson</span>, 03/26/2010) * *Response* Done. I've rewritten much of this section for clarity/readability (<span style="color: blue; text-decoration: underline">DaveJohnson</span> 04/09/2010) 1 CLOSED wouldn't it be better to update the protocol names? That means from oslc-postMessage-1.0 to oslc-postMessage-2.0 or oslc-core-postMessage-1.0 ? So clients can keep their picker/creation dialog implementations/URLs and can check the protocol to find out in which form the result has to be returned. (Martin Aeschlimann, 04/09/2010) * * *Response* Updated to use new #oslc-core-postMessage-1.0 and #oslc-core-windowName-1.0 (SteveSpeicher 04/12/2010) 1 %PURPLE%TABLED%ENDCOLOR% This is is something that we haven't implemented in RTC. I heard that RQM struggled hard to get it right. See Paul McMahon's comment in http://open-services.net/bin/view/Main/QmImplementationReports. Problems: a) The picker URL points to a ajax_module and we can't install a service on the same URL that handles the POST. Some tricks are needed, e.g. redirecting the page. b) Managing the temporary change request resource is also an effort that is not simple for clients. I suggest to remove this from the spec until we gain more experience. My suggestion for an alternative would to allow users to passing initial settings as URL parameters. (pickerURL?summary='xx'&comment='eee'. This has limitations (because of the URL length), but is simple and useful in most case (Martin Aeschlimann, 04/09/2010) * * *Response* This illustrates a limitation with some browsers and losing the window.name value on redirect, it doesn't have to do with using POST for prefill. Leaving this in the spec and setting status to tabled while we continue to investigate a workaround. A workaround is to only use postMessage. (SteveSpeicher 04/12/2010) 1 CLOSED Return value on cancel. In responses, instead of the empty string, I'd prefer an empty array or no property 'oslc:results' at all. Using the same property for both a string or an array is not so pretty. (Martin Aeschlimann, 04/09/2010) * * *Response* Made the change (SteveSpeicher 04/12/2010) 1 CLOSED Definition of Namespace in Result. The core spec has a section on the use of JSON and namespace prefixes ( http://open-services.net/bin/view/Main/OSLCCoreSpecDRAFT?sortcol=table;up=#JSON_Representation ). To be consistent, the return value should probably follow that section as well. (But it has to be said that section makes it much more complicated to consume a JSON result, due to the requirement to first resolve namespace prefixes....)(Martin Aeschlimann, 04/09/2010) * * *Response* We will align with JSON Representation guidance, though adding pre-defined prefix names for oslc, rdf, dc and foaf so JSON clients don't need to resolve (action on DaveJohnson) We will rewrite the JSON sections to follow new core terminology (SteveSpeicher 04/12/2010) 1 CLOSED Is there a need to use =oslc:message= ? (Workgroup Review, 04/12/2010) * * *Response* The property =oslc:message= has been removed (DaveJohnson 04/16/2010) 1 CLOSED The spec is not clear on the valid values for the Dialog sizing properties and does not adequately describe how a consumer is expected to use these values. (PatrickStreule 07/29/10) * * *Response* the spec was updated to make it clear that the sizing properties may have an valid relative length value as defined by the W3 CSS spec. This allows px, em, and ex relative length values and excludes absolute values. Additionally, language was added to the spec to indicate that the client is expected to use these relative length values in combination with client default system font values. (ScottBosworth 08/03/2010) ---+ Authentication 1 CLOSED do we need one required authentication mechanism? (IanGreen, 03/03/2010) * *Response* No change. We do need one mechanism, but we cannot agree on what it should be. Some folks insist on HTTP Basic, some on form-based and some on OAuth. (DaveJohnson 03/23/2010) 1 CLOSED For "OSLC Form Based Authentication" I know this is a problem, but it seems to me to be a stretch to be able to solve this in the first core spec. Perhaps something could be done via service discovery. (SteveSpeicher via DaveJohnson, 03/16/2010) * *Response* Changed text to say something like this you can use form based authentication, but if you do you must specify how it works (DaveJohnson 03/23/2010) 1 %GREEN%RESOLVED%ENDCOLOR% It states that "OSLC Services MAY protected resources with OAuth Authentication". I propose to qualify that "OSLC Services MAY......... with OAuth Authentication that uses HTTP Basic or Form-based Authentication. " This would eliminate the interpretation that OAuth with other types of Authentication is allowed. (TackTong, 03/19/2010) * *Response* No change. I don't see any reason to disallow OAuth use when other authentication mechanisms are also in use (DaveJohnson 03/23/2010) * *Response* When OAuth is being used, the Service would still need to specify how to authenticate user. If not, it may indicates that OSLC supports OAuth with Windows NTLM Authentication mechanism. I don't believe that is what you want. (TackTong. 03/29/2010) * *Response*: when OAuth is used, we don't care how user is authenticated. Any form of user authentication could be in place. 1 %GREEN%RESOLVED%ENDCOLOR% We must specify how clients can learn of the three OAuth URLs needed to do the OAuth dance, probably in the Service Resource. requirements (DaveJohnson, 03/23/2010) * *Response* ServiceProvider may now specify an oslc:OAuthConfiguration (DaveJohnson 04/16/2010) 1 %GREEN%RESOLVED%ENDCOLOR% "OSLC Services use standard web protocols for authentication. OSLC Services can use HTTP Basic Authentication, OAuth or both. " What is the rationale that Form Based is not on the list? (TackTong, 03/29/2010) * *Response* There is no standard or even a spec for Form Based auth, once there is one we can consider it for core. (DaveJohnson 04/08/2010) 1 %GREEN%RESOLVED%ENDCOLOR% Like to understand 2 legged OAuth is a "SHOULD" and its use case. (TackTong, 03/29/2010) * *Response* Two legged OAuth is a SHOULD because it allows command-line clients to get a token and call services without human assistance to login, approve access as part of the OAuth dance. See issue #8 below for further resolution (DaveJohnson 04/08/2010) 1 %GREEN%RESOLVED%ENDCOLOR% If Core does not define how Form Based Authentication would work, Reporting would have to do it. Propose to be in Core, since there may be other clients need programatic authentication with Form Based. (TackTong, 03/29/2010) * *Response* No spec change. Answering question: Yes, if reporting WG needs Form Based authentication then reporting should specify it and try to get it into Core after Core v1.0 1 <span style="color: #008000" class="Apple-style-span">RESOLVED</span> Clarify what OAuth support means, two-legged OAuth (DaveJohnson, 03/31/2010) *Response* Removed mention of two-legged OAuth (DaveJohnson 04/08/2010) 1 %GREEN%RESOLVED%ENDCOLOR% OAuthConfiguration has three properties - oslc:oauthAccessTokenURI, oslc:authorizationURI, oslc:oauthAccessTokenURI. Need more elaboration on what are these properties and how they would be use for. I have no idea why we need these. (TackTong, 04/25/2010) * *Response* These are the three OAuth URLs that a client MUST know to perform OAuth authenticationsee <span style="font-family: arial,sans-serif; font-size: 13px; border-collapse: collapse" class="Apple-style-span">See <a target="_blank" href="http://oauth.net/core/1.0a/#request_urls" style="color: #074d8f">http://oauth.net/core/1.0a/#request_urls</a> </span> for more details. (DaveJohnson 04/27/2010) ---+ Error Responses 1 %GREEN%RESOLVED%ENDCOLOR% The prefix should be oslc:, NOT oslc_cm:, and oslc:url and oslc:rel should be links to Resources as opposed to URI-valued Literal properties. (<span style="color: blue; text-decoration: underline">ArthurRyman</span>, 03/29/2010) *Response*: fixed oslc_cm problem, and oslc:url, but no change on oslc:rel which is a simple text string (<span style="color: blue; text-decoration: underline">DaveJohnson</span> 04/08/2010) 1 %GREEN%RESOLVED%ENDCOLOR% Error resource: the datatype of oslc:statusCode is Decimal. I suggest that String is more appropriate since a code is usually an arbitrary sequence of characters, not necessarily a decimal number. (ArthurRyman, 06/14/2010) * *Response* Concur and changed to string. 1 %GREEN%RESOLVED%ENDCOLOR% Error resource: the (misspelled) property oslc:exendedMessage should be oslc:extendedError since it refers to an ExtendedError resource (ArthurRyman, 06/14/2010) * *Response* Concur and changed to extended error. 1 %GREEN%RESOLVED%ENDCOLOR% Error resource: the text refers to the resource type oslc:ExtendedMessage but that should be oslc:ExtendedError (ArthurRyman, 06/14/2010) * *Response* Concur and changed to extended error. 1 %GREEN%RESOLVED%ENDCOLOR% Extended Error resource: the properly oslc:url should be renamed to the more descriptive term oslc:moreInfo since it refers to a document that contains more information. (ArthurRyman, 06/14/2010) * *Response* Concur and changed to oslc:moreInfo 1 %GREEN%RESOLVED%ENDCOLOR% Extended Error resource: the property oslc:rel has datatype Resource which is inconsistent with the text which defines a string value 'alternate'. The datatype should therefore be String (ArthurRyman, 06/14/2010) * *Response* Concur and changed to string. 1 %GREEN%RESOLVED%ENDCOLOR% Extended Error resource: the properties oslc:highWidth and oslc:hintHeight have datatype Decimal, but this is inconsistent with their use elsewhere, where it is String in order to allow CSS window size units. Use String here too. (ArthurRyman, 06/14/2010) * *Response* Concur and changed to string. ---+ Versioning 1 %GREEN%RESOLVED%ENDCOLOR% Versioning solution is not workable, how about this: if no OSLC-Version header is present then provider should return oldest/most compatible representation of resource (JimConallen>, 03/30/2010) * *Response* Spec changed as suggested (<span style="color: blue; text-decoration: underline">DaveJohnson</span> 04/xx/2010) 1 %GREEN%RESOLVED%ENDCOLOR% We need both a common version string, i.e. OSLC-Version, and domains should also specify a version string (NickCrossley, 03/30/2010) * *Response* Spec changed to rename header to OSLC-Core-Version. (<span style="color: blue; text-decoration: underline">DaveJohnson</span> 04/xx/2010) 1 %GREEN%RESOLVED%ENDCOLOR% Recommend that OSLC domains each define their own version header and also: what happens when client requests an impossible combination of Core and Domain versions? (DaveJohnson, 04/14/2010) * *Response* Yes, get this in (DaveJohnson 04/xx/2010) 1 %GREEN%RESOLVED%ENDCOLOR% Specify what happens when client requests version that server cannot satisfy: server should return closest version to one client requested (DaveJohnson, 04/14/2010) * *Response* Yes, get this in (DaveJohnson 04/xx/2010) 1 %GREEN%RESOLVED%ENDCOLOR% Use OSLC Version as domain version string, and oslc:domain to specify version string and not namespace http://open-services.net/pipermail/oslc-core_open-services.net/2010-April/000146.html * *Response* Instead, we made these changes [[OslcCoreMeetings04302010]] (DaveJohnson 05/04/2010) ---+ OSLC Defined Resource Reps 1 CLOSED need to state that property ordering is insignificant in representations (IanGreen, 03/03/2010) * *Response* Added a sub-section to explain that order is insignificant (DaveJohnson 03/23/2010) 1 CLOSED need to specify whether relative URLs be allowed in representations (IanGreen, 03/03/2010) * *Response* The specification now requires absolute URIs except where xml:base is used to allow resolution (DaveJohnson 03/xx/2010) 1 %GREEN%RESOLVED%ENDCOLOR% re: No new content-types. ArthurRyman: use "strongly discouraged" rather than MUST on the new content-types section. NickC: encourage use or standard types, discourage gratuitous new types (DaveJohnson, 03/31/2010) * *Response* Now use "strongly encourage use of existing and standard content-types" language (DaveJohnson 04/08/2010) 1 <span style="color: #008000" class="Apple-style-span">RESOLVED</span> Consensus among RDF experts seems to be that RDF/XML is not the best representation for RDF, so why do we mandate it as a MUST in the Core spec. Here are two alternatives: (DaveJohnson, 05/11/2010) * Option #1 - say this: OSLC services SHOULD provide RDF/XML representations for all resources and MAY provide Turtle, JSON or Atom representations. * Option #2 - say this: OSLC services SHOULD provide an RDF serialization, either RDF/XML or Turtle, and MAY provide JSON or Atom representations. * *Response* Workgroup consensus is against this change. Instead, I have added some paragraphs that explain why we require RDF/XML (DaveJohnson 05/11/2010) 1 <font color="limegreen" class="WYSIWYG_COLOR">RESOLVED</font> Small improvement, in the representation examples, can we use small single-digit numbers in our URLs instead of those silly hex strings? (DaveJohnson 05/21/2010) * *Response*: good idea. This change has been made. 1 %GREEN%RESOLVED%ENDCOLOR% After lengthy discussion we decided that we were in dangerous territory by mandating that folks use a subset of RDF/XML. We were inventing a new format but without a rigorous definition of the new format but what we really want is for people to use standard formats. * *Response* We decided to require RDF/XML and expect clients to be able to parse RDF/XML. We will still offer the step-by-step instructions for RDF/XML (and JSON) but we will move them out to a sepeate guidance document. Implementaitons without an RDF toolkit can still use those steps to generate representations, but clients should not expect OSLC services to adhere to that format. Here's the full proposal that we accepted and implemented in the Core (DaveJohnson 07/21/2010) * [[http://open-services.net/pipermail/oslc-core_open-services.net/2010-July/000387.html]] 1 <span style="color: #008000" class="Apple-style-span">RESOLVED</span> Proposal to change from MUST provide RDF/XML to SHOULD (DaveJohnson 07/25/2010) * See this email thread for proposal and discussion: * [[http://open-services.net/pipermail/oslc-core_open-services.net/2010-July/000416.html]] ---++ RDF/XML 1 CLOSED need to specify if XML allows use of =xml:base=? (IanGreen, 03/03/2010) * *Response* The specification now explicitly allows use of xml:base (DaveJohnson 03/23/2010) 1 CLOSED - The RDF/XML is wrong, e.g. in , there should be a element wrapping the property values. Also, there are places where you are using ==rdf:about= when you really should use =rdf:resource= (ArthurRyman, 03/03/2010) * *Response* Incorporated MN's RDF/XML fixes (DaveJohnson 03/23/2010) 1 CLOSED - The query resource representation should be used when query is against an entire service, and when query is against some subset of all resources determined by a membership property (ArthurRyman, 03/03/2010) * *Response* Keep one model for query resource, two is too confusing for clients (DaveJohnson 03/23/2010) 1 CLOSED XML/RDF representations - there are a lot of problems with the representations, missing namespace declarations, etc. Fixes are attached. (DaveJohnson for MN, 03/16/2010) * *Response* Incorporated MN's RDF/XML fixes (WikiName of resolver 03/xx/2010) 1 CLOSED The example on OSLC Service Resource RDF/XML representation does not seem matching with the specification in this document. (TackTong, 03/19/2010) * *Response* Updated the representation to match what is in the Service Resource section (DaveJohnson 03/23/2010) 1 CLOSED The example on OSLC Query Resource RDF/XML representation does not seem to be valid RDF/XML. (TackTong, 03/19/2010) * *Response* Corrected RDF/XML (DaveJohnson 03/23/2010) 1 %GREEN%RESOLVED%ENDCOLOR% Like to request adding an example of a RDF/XML representation of a Resource Shape Resource to fully understand what a Resource Shape looks like in RDF/XML. (TackTong, 03/29/2010) * *Response* Will add this (SteveSpeicher 04/16/2010) 1 %GREEN%RESOLVED%ENDCOLOR% Add use of rdf:nodeID. This is needed in some cases where a Resource node is inlined but is a blank node and you need to refer to it from another property. I ran into this situation in the EMS spec when trying to avoid the use of a complex XMLLiteral value and use RDF nodes and properties instead. (ArthurRyman, 03/29/2010) * Response: with our new Resource, Local Resource, Inline Resource, etc. terminology it was clear how to add in rdf:nodeID in the right places (DaveJohnson 04/16/2010) 1 %GREEN%RESOLVED%ENDCOLOR% Property rule 1.2 If property value is URI<br />* 1.2.1 Add to the XML element the rdf:resource attribute set to URI <br />If the definition of URI value is just a string with URI format, then it should not be rdf:resource. (TackTong, 03/29/2010) * *Response* Fixed. But, for the representation of a URI because it is a literal value, not a resource link. To link to a resource then use a Resource Value type (DaveJohnson 04/09/2010) 1 %GREEN%RESOLVED%ENDCOLOR% Property rule 1.4 Else if property value is a Node with a URI and you wish to represent it out-of-line:<br />* 1.4.1 Open XML element using QName of the Node<br />* 1.4.2 Add to the XML element the rdf:about attribute set to URI of Node<br />* 1.4.3 Close the XML element <br />I believe it should be rdf:resource instead.(TackTong, 03/29/2010) * *Response* We now use rdf:resource for the Resource type "In-Line" 1 %GREEN%RESOLVED%ENDCOLOR% OSLC Defined Resource rule 3.0 If the resource is a Query Resource, then for each query result item<br />* 3.1 Open XML element using QName of linked resource<br />* 3.2 Add to XML element the rdf:about attribute set to URI of Linked Resource<br />* 3.3 Inside the XML element represent the property values of the Linked Resource or a subset <br />Query REsource rules are defined in another section. The above should be removed.(TackTong, 03/29/2010) * *Response* Removed from spec (DaveJohnson 04/09/2010) 1 %GREEN%RESOLVED%ENDCOLOR% In the OSLC Service Resource RDF/XML Example, there are two identical QueryCapability in two different Service. Not sure it is intentional and if so, like to know the reason?(TackTong, 03/29/2010) * *Response* Corrected the Service Resource example (DaveJohnson 04/16/2010) 1 %GREEN%RESOLVED%ENDCOLOR% to support alternate languages, recommend use of xml:lang attribute in RDF/XML representations and specify a way to do this in JSON too. (ArthurRyman, 03/31/2010) * *Response* See Item #18 under resource shapes for details (DaveJohnson 04/xx/2010) 1 %GREEN%RESOLVED%ENDCOLOR% Mention that when creating a new resource and using xml:base, the representation that you post may not have absolute URIs yet, pending the assignment of a resource URI by the provider (DaveJohnson, 03/31/2010) * *Response* Yes get this in the spec (DaveJohnson 04/xx/2010) 1 %GREEN%RESOLVED%ENDCOLOR% re: Service Resources and elsewhere: use rdf:resource to carry URI value type (DaveJohnson, 03/31/2010) * *Response* This is now in the rules and elsewhere (DaveJohnson 04/xx/2010) 1 %GREEN%RESOLVED%ENDCOLOR% re: Resource Shapes. allowed values are often computed, allow them to be made available at a URI rather than inlined (SteveSpeicher, 03/31/2010) * *Response* Defined oslc:AllowedValues resource (DaveJohnson 04/09/2010) 1 <span style="color: #008000" class="Apple-style-span">RESOLVED</span> There are two types of Query Capability - Self Subject and Multi Subject. There are only rules to generating RDF/XML representation for Query Resource of type Multi Subject which starts with rdf:RDF element. The rules for generating RDF/XML representation for Query Resource of type Self Subject would be different, since it starts with a node element of the type of the Self Subject resource. (TackTong, 04/25/2010) * *Response* Document how to form a representation of a self-subject query only, multi-subject has been deleted. 1 %GREEN%RESOLVED%ENDCOLOR% RDF/XML representations should ALWAYS be rooted with <rdf:RDF> because otherwise, we cannot use the anchor form proposed in Link Guidance (DaveJohnson 06/30/2010). * *Response*: Incorporated into Abbreviated RDF/XML rules. 1 %GREEN%RESOLVED%ENDCOLOR% Need strategy for differentiating our Abbreviated RDF/XML from full RDF/XML representatons, otherwise clients who target the simple form will broken if/when we ever allow full representations. * *Response* Strategy should be allow either Full, Abbreviated or both forms of RDF/XML and use content-negotiation to determine what is returne. This has been incorporated into the spec (Dave Johnson 07/12/2010) * *See also* The email thread: [[http://open-services.net/pipermail/oslc-core_open-services.net/2010-July/000367.html]] ---++ JSON 1 %GREEN%RESOLVED%ENDCOLOR% JSON representations - Need to define XML namespace prefixes because we use them in QNames (DaveJohnson, 03/16/2010) * *Response* JSON representations now use the a mutli-valued property named =oslc:namepaceDefintion= with value-type of "Inline Local Resource of type =NamespaceDefiniton=" to declare the namespaces used (<span style="color: blue; text-decoration: underline">WikiName</span> of resolver 03/xx/2010) 1 %GREEN%RESOLVED%ENDCOLOR% In "JSON Representation", I think the first example doesn't have the multi-valued property as an array, it should be (see email to Core Mailing list) (SteveSpeicher via DaveJohnson, 03/16/2010) * *Response* Corrected (%BLUE%<u>DaveJohnson</u>%ENDCOLOR% 04/16/2010) 1 %GREEN%RESOLVED%ENDCOLOR% JSON should be required to use our predefined prefixes (DaveJohnson, 04/12/2010) * *Response*: This is now stated in both the Service Provider and JSON representation sections of the spec (DaveJohnson 04/16/2010) 1 <font color="limegreen" class="WYSIWYG_COLOR">RESOLVED</font> Because we predefine some property name prefixes, require that other prefixes are defined in the Service Provider resource and required that JSON representations use our predefined prefixes we can remove all namespace declarations from JSON (DaveJohnson, 05/10/2010) * *Response* We need prefix declarations in JSON like those in RDF/XML and Turtle, don't use oslc:prefixDefinition to do it -- instead define something more compact. (DaveJohnson 05/10/2010) 1 %GREEN%RESOLVED%ENDCOLOR% the text refers to QNames but should refer to Prefixed Name. A QName represents a pair consisting of a namespace URI and a local name. A Prefixed name represents a URI ref. (ArthurRyman, 06/14/2010) * *Response*: correct this and changed JSON property name from qname to pname. 1 %GREEN%RESOLVED%ENDCOLOR% the property rdf:id is used but this should be rdf:nodeID (ArthurRyman, 06/14/2010) * *Response*: correct this to rdf:nodeID ---++ Turtle 1 <font color="limegreen" class="WYSIWYG_COLOR">OPEN</font> The Turtle rules and examples are missing (DaveJohnson, 03/16/2010) * *Response* The Turtle rules should be automatic since we should define all resources in terms of the RDF data model. Every resource is described in terms of properties and values, and is therefore a set of triples. Defining the triples is all we have to do in order to get a standard representation in Turtle, N3 or any other RDF format. The difference between those and RDF/XML is that we are trying to make RDF/XML look like plain old XML and not require special parsing to support the more cryptic RDF/XML idioms. For Turtle and N3, there is no pretext that we are hiding the fact that the data is RDF. (ArthurRyman, 03/29/2010) ---++ Atom 1 %GREEN%RESOLVED%ENDCOLOR% The Atom rules and examples are missing (DaveJohnson, 03/16/2010) * *Response* Added rules for Atom representation of resources and query resources (DaveJohnson 04/16/2010) 1 %GREEN%RESOLVED%ENDCOLOR% Need Atom example for Query responses and make sure it shows how to do paging. (DaveJohnson, 04/27/2010) * *Response* Yes, get this in (<span style="color: blue; text-decoration: underline">DaveJohnson</span> 04/27/2010) 1 <span style="color: #008000" class="Apple-style-span">RESOLVED</span> In 1.3.3 of http://open-services.net/bin/view/Main/OSLCCoreSpecAppendixRepresentations?sortcol=table;table=up#Rules_for_forming_an_Atom_format, should the rdf:about attribute of the root element be the URI of the URI of the member value and not the query base URI of the query? * *Response*: should be the URI of the individual query result. Fixed in Guidance. ---+ Common properties 1 CLOSED RDF Properties - rdf:type is not a string, it is a URI (<span style="color: blue; text-decoration: underline">DaveJohnson</span> for MN, 03/16/2010) * *Response* Fixed (<span style="color: blue; text-decoration: underline">DaveJohnson</span> 03/19/2010) 1 CLOSED "oslc:nodeShape URI zero-or-many Node Shape Resource Shape that corresponds to current resource or node". Not sure what this is for. Would be good to have an example or a use case for it. (<span style="color: blue; text-decoration: underline">TackTong</span>, 03/19/2010) * *Response* Removed oslc:nodeShape from common properties. It should only be allowed in a Resource Shape as a property of an oslc:Property Node. (<span style="color: blue; text-decoration: underline">DaveJohnson</span> 03/23/2010) 1 CLOSED "oslc:nextPage URI zero-or-one Next Page Used in a Query Resource to indicate the next page " This indicates that oslc:nextPage is only applicable for Query Resource. I believe there may be Resources that could have bulk data and requires paging. Take your example of oslc_fm:fooReport. It could potentially have hundreds thousands oslc_fm:measurement, and thus requires paging. We need to extend paging for large Resource which is not a Query Resource. The trouble is oslc:nextPage is not really a property of the Resource, but a property of the RDF/XML representation. (<span style="color: blue; text-decoration: underline">TackTong</span>, 03/19/2010) * *Response* Changed description to indicate that property may be used in any resource (<span style="color: blue; text-decoration: underline">DaveJohnson</span> 03/24/2010) 1 CLOSED Need clarification on where in the RDF/XML can be broken for a page in oslc:nextPage. e.g. In your example of oslc:Query, is it okay to break for a page within the oslc_cm:ChangeRequest element? or the break point has to be between the second level elements below oslc:Query? This needs to be specified to set the client's expectation. (<span style="color: blue; text-decoration: underline">TackTong</span>, 03/19/2010) * *Response* Made it clear that property values may not be split (<span style="color: blue; text-decoration: underline">DaveJohnson</span> 03/24/2010) 1 CLOSED It is foreseeable that there could be two ways to implement paging at the Service. One is to cache in the complete resultset into memory and return page by page. The other is to issue server side query for one page at a time. The former would guarantee the validity of the complete resultset at time of query. However, the cache could expire before all pages are fetched from client. Thus, it needs to specify how the service should respond when cache expired and what the client should expect and react. The latter case could potentially end up with duplicates, missing records, or changed records, as records may be changed in-between pages are being queried. Thus, it needs to specify whether duplicates, missing records or changed records are allowed, or prohibited, or should be tolerated by clients. (<span style="color: blue; text-decoration: underline">TackTong</span>, 03/19/2010) * *Response* Introduced notions of Stable and Unstable Paging and explained implications (<span style="color: blue; text-decoration: underline">DaveJohnson</span> 03/24/2010) 1 CLOSED Due to all the above comments on Paging, I suggest having Paging as a separate section, rather than just as a simple Commom Property, to properly address all concerns . (<span style="color: blue; text-decoration: underline">TackTong</span>, 03/19/2010) * *Response* Yes, we should have new Paging Section (see issue #3 above) (<span style="color: blue; text-decoration: underline">DaveJohnson</span> 03/23/2010) 1 %GREEN%RESOLVED%ENDCOLOR% RDF Properties: It states rdf:type occurs zero-or-many. In OSLC Defined Resources section, it states that an OSLC Defined Resource MUST have a Type URI (aslo known as RDF type). Thus, the occurrence should be one-or-many. (<span style="color: blue; text-decoration: underline">TackTong</span>, 03/29/2010) * *Response* ?? 1 %GREEN%RESOLVED%ENDCOLOR% dc:title should be XMLLiteral and have datatype XHTML span content. dc:description should be XMLLiteral and have datatype XHTML div content. OSLC should adopt XHTML as the standard way to interchange rich text. (<span style="color: blue; text-decoration: underline">ArthurRyman</span>03/29/2010) *Response*: adopted in spec (<span style="color: blue; text-decoration: underline">DaveJohnson</span> 04/07/2010). 1 %GREEN%RESOLVED %ENDCOLOR%recommend renaming oslc:context to oslc:scope due to potential missunderstanding in ALM industry (<span style="color: blue; text-decoration: underline">RobertElves</span>03/30/2010) *Response* Done. We now use oslc:scope and describe it as "The scope of a resource is a link to the resource's<span style="color: blue; text-decoration: underline">ServiceProvider</span>." 1 %GREEN%RESOLVED %ENDCOLOR%what is the relationship to rdf:type to dc:type? some 1.0 specs used dc:type (<span style="color: blue; text-decoration: underline">SteveSpeicher</span> 03/30/2010). *Response*: there is no relation. OSLC domain specs are free to use dc:type as they wish, possibly as a way to create sub-types. 1 %GREEN%RESOLVED%ENDCOLOR% Be more specific about Dublin Core and which namespaces are we using. (<span style="color: blue; text-decoration: underline">SteveSpeicher</span>, 03/30/2010) * *Response* The spec now states that we are using the Dublin Core Metadata Element set and references the spec (<span style="color: blue; text-decoration: underline">DaveJohnson</span> 04/08/2010) 1 %GREEN%RESOLVED%ENDCOLOR% List of common properties is too short and does not really contain properties that are common across OSLC specifications - see also <span style="color: blue; text-decoration: underline">http://open-services.net/pipermail/oslc-core_open-services.net/2010-April/000140.html</span> (<span style="color: blue; text-decoration: underline">DaveJohnson</span>04/28/2010). * *Response* Yes, review domain specs to ensure we have truly common properties (<span style="color: blue; text-decoration: underline">DaveJohnson</span> 04/28/2010). 1 %GREEN%RESOLVED%ENDCOLOR% Add an =oslc:instanceShape= property to allow resources to specify their shape. See discussion here:<span style="color: blue; text-decoration: underline">http://open-services.net/pipermail/oslc-core_open-services.net/2010-April/000143.html</span> (<span style="color: blue; text-decoration: underline">DaveJohnson</span> 04/28/2010). * *Response* Yes, get this into spec (<span style="color: blue; text-decoration: underline">DaveJohnson</span> 04/27/2010) 1 %GREEN%RESOLVED%ENDCOLOR% We need a common properties specification that can be a living document, one that can grow as OSLC workgroups find common properties and get them approved for use across specs. * *Response*: Make the following two changes (DaveJohnson 05/25/2010) * *For the "living" registry of common properties*: create a new document called OSLC Core Common Properties and add to it all of the common properties that are defined in Core Spec Appendix A, but are not defined or used elsewhere in the Core spec. * *In the Core spec*: keep Appendix A as the place where we specify the common properties and resources that are defined by and used in the Core spec. 1 %GREEN%RESOLVED%ENDCOLOR% Using "dc" for new Dublin Core namespace is unconventional, but changing may break old and misbehaving clients. We are using the newer terms namespace, http://purl.org/dc/terms/ instead of the legacy elements namespace http://purl.org/dc/elements/1.1/. However, the usual prefix for the terms namespace seems to be dcterms: while the elements namespace uses dc:. I suggest we adopt this convention and use dcterms: as the predefined and recommended prefix. See also [[http://open-services.net/pipermail/oslc-core_open-services.net/2010-May/000256.html]] (ArthurRyman 05/26/2010). * *Response*: After much mailing list discussion, we wwitched to using the new "dcterms" prefix, updated all specs and diagram. 1 %GREEN%RESOLVED%ENDCOLOR% Second, we had a long email discussion on using rich text for these properties, specifically XHTML <span> and <div> content, and this is recommended in Appendix A. [3] This means the datatype should be rdf:XMLLiteral. However, the Core uses string for these on its own resources. Shouldn't we follow our own recommendations? (ArthurRyman, 06/14/2010) * *Response*: Concur and changed resource shape's title and description value-types to XMLLiteral. 1 %GREEN%RESOLVED%ENDCOLOR% We do not want to enable rigid schemas and we're not convinced that Resource Shapes are useful beyond Resource Creation, Query and possibly some constrained form of update. So, we should not tie shapes to types and the =oslc:instanceShape= property should be removed from the common properties. (DaveJohnson on behalf of Martin Nally, 06/14/2010). * *Response* Keep in spec but explain its purpose and that resource shapes are intended to give clients simple "hints" at creation, update and query time but not intended to form a rigid constraint system or validating inputs or schema system for generating "binding" classes for Java or any other programming language. 1 %GREEN%RESOLVED%ENDCOLOR% It appears that the list of common Dublin Core properties has been inadvertently shortened - only 3 are listed now though earlier versions of the spec had a much longer list (and many domain specs are making use of other common DC properties). Can we get the full list back in the spec? (ScottBosworth, 07/13/2010). * *Response* They were moved out to a separate "living" Common Properties document so that they were not in the list of properties to be frozen with the Core. Since then we realized that we want only one list of properties and we want it to be living and grow under the management of the OSLC Core workgroup.
E
dit
|
A
ttach
|
P
rint version
|
H
istory
: r1
|
B
acklinks
|
V
iew topic
|
Ra
w
edit
|
M
ore topic actions
Topic revision: r1 - 21 Sep 2011 - 15:00:23 -
SteveSpeicher
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