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)

OSLC Core Spec V2 Issues (during Convergence phase)

This document captures the issues raised against the OSLC Core Spec v2 during the convergence phase

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:

  • OPEN - indicates that we have no response for the issue yet
  • RESOLVED - 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
  • DEFERRED - indicates that issue will be addressed in Core Guidance v1.0 during the month after the Core Specification is final.
  • TABLED - indicates that issue will be reconsidered at some later but unspecified date

Overall

  1. DEFERRED 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)
  2. DEFERRED 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 https://jazz.net/wiki/bin/view/Sandbox/CompactRenderingV1P1 (ScottBosworth, 03/04/2010)
    • Response Yes but as separate guidance (DaveJohnson 03/18/2010)
  3. DEFERRED 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)
  4. DEFERRED 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)
  5. 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)
  6. 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 "The purpose of these specifications is to enable integration between products that support Application Life-cycle Management (ALM) and Product Life-cycle Management (PLM)" (DaveJohnson 03/18/2010)
  7. 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 (DaveJohnson 03/18/2010)
  8. 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 (DaveJohnson 03/18/2010)
  9. 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)
  10. 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)
  11. 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)
  12. 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)
  13. RESOLVED 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)
  14. RESOLVED 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)
  15. RESOLVED 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)
  16. RESOLVED 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.
  17. RESOLVED 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)
  18. RESOLVED 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).
  19. OPEN A couple of issues in http://open-services.net/bin/view/Main/OSLCCoreSpecRDFXMLExamples:

OSLC Defined Resources

  1. 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)
  2. 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)
  3. 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)
  4. 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)
  5. 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 (DaveJohnson 03/18/2010)
  6. 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)
  7. 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)
  8. 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)
  9. RESOLVED 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)
  10. RESOLVED 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)
  11. RESOLVED 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
  12. RESOLVED 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)
  13. RESOLVED 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)
  14. RESOLVED 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
  15. DEFERRED 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. 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 (DaveJohnson 04/07/2010)
  16. TABLED Some resources need to have ordered properties, can we introduce an ordered a value-type for “Ordered Resource” (reporter, 03/31/2010)
    • Response Propose we table this until we have sufficient use cases (DaveJohnson 04/13/2010)
  17. RESOLVED 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
  18. TABLED 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)
  19. RESOLVED 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.
  20. RESOLVED 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)
  21. RESOLVED 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)
  22. RESOLVED 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.
  23. RESOLVED 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)
  24. RESOLVED 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)
  25. RESOLVED 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?
  26. RESOLVED 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).
  27. RESOLVED 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)
  28. RESOLVED 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)
  29. RESOLVED 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):
    identifier ::= PrefixedName?
    PrefixedName ::= /-- see "SPARQL Query Language for RDF", http://www.w3.org/TR/rdf-sparql-query/#rPrefixedName --/
  30. RESOLVED 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.
  31. RESOLVED 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)
  32. RESOLVED 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)
  33. RESOLVED 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).
  34. RESOLVED 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):
    identifier ::= PrefixedName?
    • Response Previously added the identifier production to the oslc.where section. (ArthurRyman, 07/27/2010)
  35. RESOLVED 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).
  36. RESOLVED 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. ",").
  37. RESOLVED The oslc.select query parameter syntax is missing the properties production in the BNF grammar.
  38. RESOLVED 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)

Service Resources

  1. CLOSED Service Resources - My brain had trouble parsing the opening sentence smile 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)
  2. 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)
  3. 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)
  4. 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)
  5. 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)
  6. 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)
  7. 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)
  8. 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)
  9. 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)
  10. 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)
  11. 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 (DaveJohnson 04/07/2010)
  12. 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 (DaveJohnson 04/07/2010)
  13. 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
  14. 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 (DaveJohnson 04/07/2010)
  15. RESOLVED ‘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 "a string representation of URI, not intended to be a link but could be a base for forming other URIs" and we describe the creationURI as "to create a new resource via the factory, post it to this URI" DaveJohnson 04/xx/2010)
  16. RESOLVED >> 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)
  17. RESOLVED 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)
  18. RESOLVED 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 "The scope of a resource is a link to the resource's ServiceProvider" (DaveJohnson 04/xx/2010)
  19. RESOLVED 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)
  20. 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)
  21. RESOLVED 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)
  22. RESOLVED 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).
  23. RESOLVED 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).
  24. RESOLVED In the oslc:Property: namespace and valueType not be a URIs, it should be a resource (DaveJohnson, 04/19/2010)
    • Response Yes. This is now reflected in the spec. (DaveJohnson 04/19/2010).
  25. RESOLVED 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)
  26. RESOLVED 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)
  27. RESOLVED 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
  28. RESOLVED 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.
  29. RESOLVED 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"
  30. RESOLVED 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.
  31. RESOLVED 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)
  2. 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)
  3. 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)
  4. 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)
  5. RESOLVED 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:

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)
  2. 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)
  3. 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)
  4. 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)
  5. CLOSED For "URI Query Parameters", this should also include "oslc.prefix" to allow for defining namespace prefixes (SteveSpeicher via DaveJohnson, 03/16/2010)
    • Response Will be addressed in Query Syntax section (DaveJohnson 03/23/2010)
  6. 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)
  7. 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)
  8. RESOLVED 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)
  9. 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)
  10. 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)
  11. RESOLVED 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)
  12. RESOLVED "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.
  13. RESOLVED 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)
  14. RESOLVED 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).
  15. RESOLVED 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).
  16. RESOLVED 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).
  17. RESOLVED 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)
  18. RESOLVED 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
  19. RESOLVED 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
  20. RESOLVED 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)
  21. RESOLVED 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
  22. RESOLVED 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)
  23. RESOLVED 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)
  24. RESOLVED 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)
  2. 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)
  3. 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)
  4. 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)
  5. 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)
  6. 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)
  7. 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)
  8. 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)
  9. 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)
  10. RESOLVED "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)
  11. RESOLVED 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
  12. RESOLVED 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)
  13. RESOLVED 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)
  14. RESOLVED 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 (DaveJohnson 04/07/2010)
  15. RESOLVED 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)
  16. RESOLVED 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)
  17. RESOLVED A Resource Shape should define what rdf:type that it is defining. (DaveJohnson, 03/31/2010)
  18. RESOLVED 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. (SteveSpeicher, 04/07/2010)
  19. RESOLVED 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)
  20. RESOLVED 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)
  21. RESOLVED 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)
  22. RESOLVED 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)
  23. RESOLVED 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).
  24. RESOLVED 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)._
  25. RESOLVED 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)
  26. RESOLVED 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.
    Suggest using oslc:onProperty since it is similar to owl:onProperty
    • Response: Concur and made recommended change.
  27. RESOLVEDValue-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.
  28. RESOLVED The namespace for the Resource value-types includes "oslc-core" but the normal core namespace just includes "oslc", not "oslc-core". Use just one
    base URI for all URI refs in the core.
    • Response: Concur and made recommended change.
  29. RESOLVED The datatype of oslc:maxSize is Number which is not a datatype. Use Integer.
    • Response: Concur and made recommended change.
  30. OPEN 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-services.net/ns/core#.

Delegated User Interface

  1. CLOSED Delegated UI section needs some work to bring it in line with the Core spec terminology. (DaveJohnson, 03/26/2010)
    • Response Done. I've rewritten much of this section for clarity/readability (DaveJohnson 04/09/2010)
  2. 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)
  3. TABLED 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)
  4. 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) *
  5. 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)
  6. 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)
  7. 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)
  2. 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)
  3. RESOLVED 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.
  4. RESOLVED 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)
  5. RESOLVED "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)
  6. RESOLVED 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)
  7. RESOLVED 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
  8. RESOLVED Clarify what OAuth support means, two-legged OAuth (DaveJohnson, 03/31/2010) Response Removed mention of two-legged OAuth (DaveJohnson 04/08/2010)
  9. RESOLVED 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)

Error Responses

  1. RESOLVED 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. (ArthurRyman, 03/29/2010) Response: fixed oslc_cm problem, and oslc:url, but no change on oslc:rel which is a simple text string (DaveJohnson 04/08/2010)
  2. RESOLVED 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.
  3. RESOLVED 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.
  4. RESOLVED 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.
  5. RESOLVED 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
  6. RESOLVED 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.
  7. RESOLVED 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. RESOLVED 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 (DaveJohnson 04/xx/2010)
  2. RESOLVED 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. (DaveJohnson 04/xx/2010)
  3. RESOLVED 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)
  4. RESOLVED Specify what happens when client requests version that server cannot satisfy: server should return closest version to one client requested (DaveJohnson, 04/14/2010)
  5. RESOLVED 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

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)
  2. 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)
  3. RESOLVED 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)
  4. RESOLVED 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)
  5. RESOLVED 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.
  6. RESOLVED 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
  7. RESOLVED Proposal to change from MUST provide RDF/XML to SHOULD (DaveJohnson 07/25/2010)

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)
  2. 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)
  3. 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)
  4. 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)
  5. 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)
  6. CLOSED The example on OSLC Query Resource RDF/XML representation does not seem to be valid RDF/XML. (TackTong, 03/19/2010)
  7. RESOLVED 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)
  8. RESOLVED 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)
  9. RESOLVED Property rule 1.2 If property value is URI
    * 1.2.1 Add to the XML element the rdf:resource attribute set to URI
    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)
  10. RESOLVED Property rule 1.4 Else if property value is a Node with a URI and you wish to represent it out-of-line:
    * 1.4.1 Open XML element using QName of the Node
    * 1.4.2 Add to the XML element the rdf:about attribute set to URI of Node
    * 1.4.3 Close the XML element
    I believe it should be rdf:resource instead.(TackTong, 03/29/2010)
    • Response We now use rdf:resource for the Resource type "In-Line"
  11. RESOLVED OSLC Defined Resource rule 3.0 If the resource is a Query Resource, then for each query result item
    * 3.1 Open XML element using QName of linked resource
    * 3.2 Add to XML element the rdf:about attribute set to URI of Linked Resource
    * 3.3 Inside the XML element represent the property values of the Linked Resource or a subset
    Query REsource rules are defined in another section. The above should be removed.(TackTong, 03/29/2010)
  12. RESOLVED 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)
  13. RESOLVED 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)
  14. RESOLVED 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)
  15. RESOLVED 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)
  16. RESOLVED 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)
  17. RESOLVED 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.
  18. RESOLVED 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.
  19. RESOLVED 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.

JSON

  1. RESOLVED 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 (WikiName of resolver 03/xx/2010)
  2. RESOLVED 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 (DaveJohnson 04/16/2010)
  3. RESOLVED 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)
  4. RESOLVED 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)
  5. RESOLVED 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.
  6. RESOLVED the property rdf:id is used but this should be rdf:nodeID (ArthurRyman, 06/14/2010)
    • Response: correct this to rdf:nodeID

Turtle

  1. OPEN 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. RESOLVED 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)
  2. RESOLVED Need Atom example for Query responses and make sure it shows how to do paging. (DaveJohnson, 04/27/2010)
    • Response Yes, get this in (DaveJohnson 04/27/2010)
  3. RESOLVED 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 (DaveJohnson for MN, 03/16/2010)
    • Response Fixed (DaveJohnson 03/19/2010)
  2. 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. (TackTong, 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. (DaveJohnson 03/23/2010)
  3. 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. (TackTong, 03/19/2010)
    • Response Changed description to indicate that property may be used in any resource (DaveJohnson 03/24/2010)
  4. 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. (TackTong, 03/19/2010)
    • Response Made it clear that property values may not be split (DaveJohnson 03/24/2010)
  5. 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. (TackTong, 03/19/2010)
    • Response Introduced notions of Stable and Unstable Paging and explained implications (DaveJohnson 03/24/2010)
  6. 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 . (TackTong, 03/19/2010)
    • Response Yes, we should have new Paging Section (see issue #3 above) (DaveJohnson 03/23/2010)
  7. RESOLVED 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. (TackTong, 03/29/2010)
    • Response ??
  8. RESOLVED 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. (ArthurRyman03/29/2010) Response: adopted in spec (DaveJohnson 04/07/2010).
  9. RESOLVED recommend renaming oslc:context to oslc:scope due to potential missunderstanding in ALM industry (RobertElves03/30/2010) Response Done. We now use oslc:scope and describe it as "The scope of a resource is a link to the resource'sServiceProvider."
  10. RESOLVED what is the relationship to rdf:type to dc:type? some 1.0 specs used dc:type (SteveSpeicher 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.
  11. RESOLVED Be more specific about Dublin Core and which namespaces are we using. (SteveSpeicher, 03/30/2010)
    • Response The spec now states that we are using the Dublin Core Metadata Element set and references the spec (DaveJohnson 04/08/2010)
  12. RESOLVED List of common properties is too short and does not really contain properties that are common across OSLC specifications - see also http://open-services.net/pipermail/oslc-core_open-services.net/2010-April/000140.html (DaveJohnson04/28/2010).
    • Response Yes, review domain specs to ensure we have truly common properties (DaveJohnson 04/28/2010).
  13. RESOLVED Add an oslc:instanceShape property to allow resources to specify their shape. See discussion here:http://open-services.net/pipermail/oslc-core_open-services.net/2010-April/000143.html (DaveJohnson 04/28/2010).
    • Response Yes, get this into spec (DaveJohnson 04/27/2010)
  14. RESOLVED 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.
  15. RESOLVED 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.
  16. RESOLVED 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.
  17. RESOLVED 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.
  18. RESOLVED 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.
Edit | Attach | Print version | History: r1 | Backlinks | Raw View | Raw edit | More topic actions
Topic revision: r1 - 21 Sep 2011 - 15:00:23 - SteveSpeicher
 
This site is powered by the TWiki collaboration platform 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