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>RmHome>RmSpecificationV2Issues (revision 50)

Issues on RmSpecificationV2

  • CLOSED. [DT] In the table of Base Requirements, the Query Capabilitiesrow is inconsistent between MUST and SHOULD. Changed SHOULD to MUST.
  • CLOSED. [DT] Next row in same table should be MUST/MAY following the pattern used in the other row. Removed the second clause. This is redundant.
  • CLOSED. [DT] Basic Authentication row should be MUST/SHOULD. Added SHOULD. I've not repeated this in the column since i think the table is indended to capture "at a glance" those conditions that are directly related to the OSLC domain specification. In this case, I think a single MAY is sufficient.
  • CLOSED. [DT] OAuth Authentication row contains "can" in the description. Should it be MAY/SHOULD? Agreed. Changed to MAY (rather than SHOULD).
  • CLOSED. [DT] JSON Representation row should be MAY/MUS. Inserted MUST.
  • CLOSED. [DT] Namespaces - it's a bit odd reserving the namespace prefix isn't it? Will this lead to implementors assuming the prefix as well as, or instead of, the actual namespace? No intention that this is mandatory. I've inserted "preferred" to carry this conotation. How does a third-party query with its own namespace prefix? Third parties can use their own namespace prefixes in query by using "oslc.prefix", which is defined in the OslcCoreSpecification.
  • CLOSED. [DT] Resource Formats - the link to "OSLC Core Representations Guidance" is broken in the bulleted list. Agreed. Need to identify where the reference should point. Fixed. Updated to point to the sectioin in the Core on "OSLC Resource Representations".
  • CLOSED. [DT] In the PUT/POST format section of Resource Formats, the RDF/XML line should include "with media-type application/rdf+xml". Inserted this clause.
  • CLOSED [DT] Final paragraph of Resource formats does not bold the MUST/MAY words. Added markup
  • CLOSED [DT] Content Negotiation section - last sentence appears to contradict previous statement that "RM Providers MUST support XML representations". Reworded. This section removed and new words on resource formats added. Where a request indicates a preference for these three formats, then the server must respond with the preferred format. Server MUST honour requests for these formats.
  • CLOSED [DT] Requirement Resource - this section starts off saying requirements may (small "may) have this set of properties. is this a MAY? are some of the properties MUST have? If Occurs=="Exactly-Once" is that the same as a MUST? Reworded to avoid use of may in this context.
  • CLOSED . [DT] Resource RequirementCollection? . Has the same question on it as the previous comment. Also the initial paragraph includes OPTIONAL which should be bold. Updated OPTIONAL to be bold. Reworded as per Requirement.
  • CLOSED. [DT] Various more MUST/MAY which are not bold - I suggest a search for them. Added markup after a search for those keywords.
  • CLOSED. [DT] Afer the table on RM Relationship Properties there is a paragraph about dc:title on links. That paragraph should have a title such as "Clarification on dc:title for links". Added a section.
  • CLOSED [DT] Service provider resources. typos - "a implementation" appears at least twice. Fixed typos.
  • [DT] Version Compatability. In the second paragraph what does "...should only preserve..." mean? "only"implies some things are not preserved - what are those things?Looking at the next sentence I think I know what you mean but it's not very clear. Are you suggesting that for some URIs (that do change between v1 and v2) the provider should serve the v2 urls even when returning v1 data?
  • CLOSED (IanGreen) How do these tables refer to core - by reference or by value? Is this a private copy, or is it a reference to the oslc core specification? Perhaps "core spec wins" would be enough? Updated - asked Core lead for gudiance. Discussed at conf call Dave confirmed that domain specs take ownership of these properties.
  • CLOSED (ScottBosworth) Per Core workgroup guidance on relationships and links, we need to clarify in the specification where link properties have URI endpoints that must be of a certain type or may be of any type. 6th October: updated all link properties in the RM resources to indicate when clients can expect a specific type of resource at the uri endpoint (e.g. oslc:serviceProvider) and when clients cannot make assumptions about the type of resource at the uri endpoint (e.g. dcterms:creator, oslc_rm:elaboratedBy). 31-March-2011: Closed.
  • CLOSED (IanGreen): Do we want oslc_rm:related, or oslc_rm:relatedRequirement? There are terms from the DC namespace that might be preferred. However, are we in a position to enshrine very general relationship types at this stage? The risk is that such generalities come to mean nothing. 9th Aug: Suggestion: remove these generalities from V2 specification. Seconded by Scott consistent with CM and QM. Including pointing at something which is not an OSLC defined resource. Provider could use it's own namespace, or could use oslc:relation, for example. Move to remove these from the specification. 9th Aug: removed from the spec. CLOSED.
  • CLOSED (IanGreen): Position on partial update - how can we leave this as a MAY, and allow it to be discovered? DaveJohnson - seems to make sense that partial update capability could be discovered. AndyBerner - how difficult is it for clients to implement the get/update/put semantics on resources. This is not a performance issue alone - so should not be treated as a MAY. AndyBerner would like to see a sample of what's required at the client. IanGreen to ask SteveSpeicher about this topic, see if he can contribute. SteveSpeicher's view was that partial update would make like easier for clients; however, that initial feedback on the CM 2.0 implementation effort was that a MUST on partial update was overly burdensome (on the provider). The discovery issue can be dealt with as a special case of failure to do the partial update - a 501 in the case that the partial update is not supported. Clients getting such a response in this case could retry with a PUT. Andy: How hard are are making it for clients? 9th Aug: Move to make this a MAY. CLOSED 9th Aug: Partial Update now MAY.
  • CLOSED (AndyBerner): Need mechanism for deprecation, and what the rules are for who/when/why breaking changes can be made. DaveJohnson will take this to the OSLC Core. 31-March-2011: Deferred beyond V2.0.
  • CLOSED (IanGreen): Domain specs normally tighten - providers offering more than RM requires but which is covered by Core, MUST use Core rules. Clarify this in the RM spec. CLOSED 9th August. Clarified what additional constraints are imposed by RM spec. Primarily, this is narrowing to RDF/XML and that RDF/XML MUST have a top-level rdf:RDF element.
  • CLOSED (IanGreen): AndyBerner: Clarify What is an oslc:Discussion (one, or many etc.) Action: to discuss intended semantics. CLOSED Intention, from what i see on OSLCCoreSpecAppendixADRAFT, is that a discussion is a thread, and we want several threads. So i've changed the spec. to be zero-or-more. 9th Aug: Reopened: would like a more satisfying response from the OSLC Core team on intended usage of Discussion term. 26-aug: Slipped up and did not ask OSLC Core lead about this. Have now done so.31-Aug Response from Dave Johnson explains that this predicate arose from the CM workgroup, and was moved into OSLC Common Properties to promote its reuse. Whilst not strongly motivated, adoption of a zero-or-more oslc:Discussion seems resonable. I'm concerned about the lack of agreement with the CM spec, where the same property has zero-or-one multiplicty, so would not take too much pushing to pull this from the V2.0 spec., pending further discussion. UPDATED: Asked Andy to respond, and close if he is satisfied. 01-sept: After further thought it occurs to me that this design requires that the discussion exist before the requirement can reference that discussion (the property supports, but does not require, Inline Representation). This seems the wrong way around to me. A discussion should point to the things it discusses. A discussion is meaningless unless it discusses something. A Discussion resource has a discussionAbout property which points back to the thing being discussed, so we have a link in both directions. This seems redundant (given that we have query) and prone to inconsistencies. I'm shall remove discussions from the V2 specification, and table a question as to how and when RM should surface discussions on requirements. 6th Sept: Agreed to drop from the spec.
  • CLOSED (IanGreen): dcterms:type vs. rdf:type consistency. We need discussion around this. I cannot see that these can be aligned so unless we agree on some convention, i'd prefer to drop the dc:terms. The idea behind dcterms:type was to provide some representation of the rdf:type (a human-readable one) . Dropping this readable name means that other means, outwith OSLC, will be needed to describe these types.
  • CLOSED (IanGreen): dcterms:type still in collections resource. CLOSED 9th Aug - removed.
  • CLOSED (IanGreen): Inconsistency of link names - eg validatedBy or validatedByTestCase. CLOSED: I've achieved consistency by removing the type mnemonic. So implementBy, rather than implementedByChangeRequest. 9th Aug. Much discussion on this topic: we agreed that this is rigid, and will be likely be bad in the future. Ian to circulate email to the workgroup on this topic. explosion of type. Do we explain that query could be used to deal with this case. Clients need to be resilient. Update 9th Aug. Send email to workgroup list. Updated spec to reflect my proposal for type-free predicate names.
  • CLOSED (IanGreen): Missing property on collection for those requirements that are collected. CLOSED: I've added oslc_rm:uses.
  • CLOSED (IanGreen): wording on creation factories is clumsy (MAY have factories). CLOSED: reworded.
  • CLOSED (IanGreen): do we need query to be a MUST? why not a MAY? CLOSED: Downgraded to a SHOULD
  • CLOSED (IanGreen): delegated ui - if there is only one, it should be selection, not creation. CLOSED 9th Aug - spec REQUIRES creation and selection.
  • CLOSED (IanGreen): delegated ui - should pre-filling be MUST? CLOSED: CHanged to SHOULD. There are some minor technical challenges associated with implementation of this service. Prefilling leads to a better user experience but is not essential.
  • CLOSED (PaulMcMahan): A common scenario will involve web browsers acting as clients of an RM provider. Web browsers are not currently well suited to handle all possible forms of rdf+xml. Can the RM spec provide additional language describing how the service provider should respond when the client requests application/xml or application/json? For example, should the service provider respond to a request for application/xml with RDF/XML conforming to the guidance from core? 7/29/2010. In a web 2.0 setting, browsers will be issuing XHRs with the required accept headers. Raw browsers (GET on application/html etc) accessing OSLC resources could default to some HTML representation - I can see this being useful for example, in troubleshooting. Downside to making this a requirement in the spec. is that it increases the burden on providers. 11-Aug: UPDATED: Downgraded the need for alternative representations from SHOULD to MAY. I don't consider HTML representations to be part of our integration scenarios, and don't want to uncessarrily burden providers. Of course, providers are free to implement other resource formats, as desired. 27-aug: Paul accepted this response. CLOSED. 29-Sept: Reopened during finalization due to feedback from implementors. Workgroup considering json or application/xml representations (or both). UPDATED 7th Oct: added support for application/xml as REQUIRED. Query results continue to require RDF/XML Pending resolution of item below which has been raised.
  • CLOSED (IanGreen): Allow polymorphic resources. For example, a requirement has rdf:type oslc_rm:Requirement, but may also have other rdf:types, for example, oslc_am:Resource or oslc_cm:PlanItem (the latter is a hypothetical OSLC resource). Action (img): this is already admitted by the OSLC core specification, so perhaps some illuminating examples would suffice. CLOSED 9th Aug - no longer an issue, as a result of other changes. RDF/XML examples can illustrate this.
  • CLOSED (IanGreen): Track recent changes in OSLC Core. CLOSED 9th Aug. done this.
  • CLOSED (IanGreen): Consistency across QM, CM, AM.CLOSED 9th Aug. Updated in line with other specs.
  • CLOSED (IanGreen): Generalize ranges so that they don't constrain the nature of the object resource. UPDATED 9th Aug - updated spec so that range is "unspecified". Not yet closed since awaiting feedback from the mailing list. 17-Aug: CLOSED - No responses on the mailing list.
  • CLOSED (SteveSpeicher) I noticed that the RM 2.0 draft specs name use of dcterms:name. I might
    recommend that RM look at changing its usage to more align with what CM
    and QM (and core) are saying with some Dublin Core properties, namely:
    dcterms:abstract and dcterms:title. UPDATED 9th Aug - I believe that in this regard the CM, RM, QM specs are in agreement. Please confirm and I will close this issue. 27-aug: Steve confirmed. CLOSED.
  • CLOSED (IanGreen): REQUIRE top-level rdf:RDF in all RDF/XML representations. Updated 9th Aug - done. Expressed as a further constraint over rdf+xml media-type. I've left it permissible for a provider to accept RDF/XML that does not have this top-level element. All providers MUST include this element in all the RDF/XML they generate.
  • CLOSED (IanGreen): investigate replacing oslc_rm:relatedTo with dcterms:relation or dtcterms:requires or dcterms:reference. CLOSED 9th Aug. Agreed on today's conf call that there is no need to have this predicate. the meaning is weak, and has not arisen out of scenario discussions. Rather than bake this into the spec, we leave it for futher investigation.
  • CLOSED (IanGreen): need to address foaf issue for contributor/creator. 28-aug: Reworded so that FOAF is SHOULD, and these resources can be inlined or reference.
  • CLOSED (IanGreen): Need to provide more guidance on links. (Eg OSLC Core Link Guidance. UPDATED: 28-aug: Some words for placeholder.01-Sept: Revised wording after discussion on OSLC Core mailing list.
  • CLOSED (IanGreen): MUST on Creation Factories is too strong - no need that a provider should support creation of resources. 20-Aug: pulled this back to a MUST/MAY. I don't see the need for the specification to REQUIRE creation of resources at all; however, with a MAY/MAY, the 2.0 spec. places fewer demands on a provider. My proposal is to weaken the spec. to MAY/MAY here. 28-aug Some reconsideration here since moving from MUST to MAY on requirement creation is a retrograte step from RM 1.0. Rejecting as CLOSED
  • CLOSED (IanGreen) OSLC Core standardized on use of "any" rather than "unspecified".
  • CLOSED (IanGreen) cite the RDFS at .../ns/rm
  • CLOSED (IanGreen) Ensure that shape-free queries cover usage of rdfs:member. Update the specification to this effect.
  • OPEN (IanGreen, thanks to JimConallen) Example service provider resource does not contain REQUIRED oslc:details. Also, there is a stray dcterms:description in the sample requirement.
  • OPEN (IanGreen) need exampe requirementcollection.
  • CLOSED (IanGreen) updates to the covenant and ensure that this has been confirmed by participants. 31-March-2011: All declarations now in place.
  • CLOSED (IanGreen) how does rdf:parseType="Literal" surface in XML & JSON representations?
  • DEFERRED (IanGreen) how does xml:lang surface in JSON? Dave: There is no way to distinguish between these. Deferred for future (not an issue presently).
  • CLOSED query results are not stable- specifiy that query results are not REQUIRED to be stable. Updated the specification to this effect.
  • CLOSED ServiceProviderCatalog? OR the Service resource MUST indicate that the oslc:domain is ".../rm#".Updated.
  • CLOSED Await Implementation Report before signing off. Ian took action to include OSLC RM 2.0 implementatation reports. Implementation reports will be added as and when they are available.
  • CLOSED RmSpecificationV2Shapes examples contained some typos in the use of oslc:valueType (thanks to VP for pointing this out. IanGreen updated this examples page.
  • OPEN V2.0 specification is missing some vocabulary elements, oslc_rm:elaborates and oslc_rm:specifies. These missing vocabulary items were discussed at regular workgroup meeting (RmMeetings20110919) where it was agreed that these predicates were valuable in as far as known scenarios required them (see for example, RmElaborationBusinessRequirements), but that there were unanswered questions on (i) how these missing vocabulary items be introduced, and (ii) that the connection between oslc_rm:elaboratedBy and oslc_rm:elaborates remained unclear. [ Agreed that relationship between elaborates and elaborateBy should not be defined by RM specification. ]
    • An errata for V2.0 specification (3 May 2011) has been created - V2 errata.
    • A new revision of the V2.0 specification which addresses these omissions has been created - RM 2.0 rev 47? . (Notice that this revision is subject to change as this issue is progressed.)

Core Issues

-- IanGreen - 25 Jun 2010

Edit | Attach | Print version | History: r51 < r50 < r49 < r48 < r47 | Backlinks | Raw View | Raw edit | More topic actions...
Topic revision: r50 - 30 Jan 2012 - 16:10:06 - IanGreen
 
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