${taskforce.name} Avatar
  1. OMG Task Force

hData REST Binding for RLUS 1.0 (hData) FTF — All Issues

  • Key: HDATA
  • Issues Count: 48
Open Closed All
All Issues

Issues Summary

Key Issue Reported Fixed Disposition Status
HDATA-48 Create a paragraph in section 6.5 clarifying how resource URL paths are constructed Hdata 1.0b1 Hdata 1.0 Resolved closed
HDATA-47 Create a subsection in section 6.1.2 to identify forbidden keywords in paths for URLs Hdata 1.0b1 Hdata 1.0 Resolved closed
HDATA-46 6.4 baseURL/sectionpath Hdata 1.0b1 Hdata 1.0 Resolved closed
HDATA-43 Revise current (20121004) JSON representation of Atom feed and data in section 6.1.2 Hdata 1.0b1 Hdata 1.0 Resolved closed
HDATA-42 Conformance statement Hdata 1.0b1 Hdata 1.0 Resolved closed
HDATA-41 subscription push Hdata 1.0b1 Hdata 1.0 Resolved closed
HDATA-37 Represent DELETE in Atom: XML Fragment in Atom:Content Hdata 1.0b1 Hdata 1.0 Resolved closed
HDATA-36 mime type for format parameter (text/xml vs. xml) Hdata 1.0b1 Hdata 1.0 Resolved closed
HDATA-45 Change 6.5.3 to allow PUT creation of new documents to allow the client to suggest location. Same semantics as 6.4.2.2 Hdata 1.0b1 Hdata 1.0 Resolved closed
HDATA-40 search extensions (include as non-normative examples) Hdata 1.0b1 Hdata 1.0 Resolved closed
HDATA-39 Atom feed link:rel needs to be version specific Hdata 1.0b1 Hdata 1.0 Resolved closed
HDATA-44 discuss impact of deletion of resources/SectionDocuments onto the Section level Atom feed/JSON bundle to section 6.4.4 Hdata 1.0b1 Hdata 1.0 Resolved closed
HDATA-35 Inconsistent spelling for extensionId in parameter list for 6.2.2 Hdata 1.0b1 Hdata 1.0 Resolved closed
HDATA-38 Content override in two party update Hdata 1.0b1 Hdata 1.0 Resolved closed
HDATA-4 Lack of a Normative References section Hdata 1.0b1 Hdata 1.0 Resolved closed
HDATA-7 7.1 line 2: “This pattern may be combined” – unclear what it may be combined with. Hdata 1.0b1 Hdata 1.0 Resolved closed
HDATA-6 6.1.1 penultimate sentence, typo “this documents” Hdata 1.0b1 Hdata 1.0 Resolved closed
HDATA-3 RESTful vs. REST Hdata 1.0b1 Hdata 1.0 Resolved closed
HDATA-2 security negotiation through the use of custom HTTP headers Hdata 1.0 open
HDATA-5 Section 3, 3rd definition: typo “is access” Hdata 1.0b1 Hdata 1.0 Resolved closed
HDATA-1 separate the general RESTful pattern use from the hData specific features Hdata 1.0b1 open
HDATA-26 Metadata Communication Hdata 1.0b1 Hdata 1.0 Resolved closed
HDATA-25 Intermediaries Consideration Hdata 1.0b1 Hdata 1.0 Resolved closed
HDATA-24 Simple search Hdata 1.0b1 Hdata 1.0 Resolved closed
HDATA-23 Validation service Hdata 1.0b1 Hdata 1.0 Resolved closed
HDATA-33 Comments on Section 9 Hdata 1.0b1 Hdata 1.0 Resolved closed
HDATA-32 Comments on Section 8 Hdata 1.0b1 Hdata 1.0 Resolved closed
HDATA-30 Comments on Section 6 Hdata 1.0b1 Hdata 1.0 Resolved closed
HDATA-29 Comments on Section 3 Hdata 1.0b1 Hdata 1.0 Resolved closed
HDATA-28 Comments on Section Hdata 1.0b1 Hdata 1.0 Resolved closed
HDATA-31 Pattern for reliability Hdata 1.0b1 Hdata 1.0 Resolved closed
HDATA-34 Need clarificaton for server response to client request using the Max-Forwards header field Hdata 1.0b1 Hdata 1.0 Resolved closed
HDATA-22 Alternate content negotiation Hdata 1.0b1 Hdata 1.0 Resolved closed
HDATA-27 no clear conformance point Hdata 1.0b1 Hdata 1.0 Resolved closed
HDATA-21 Enable the use of version-aware resource URLs Hdata 1.0b1 Hdata 1.0 Resolved closed
HDATA-20 Section 6.5.1 should specify allowing negotiation through HTTP Accept headers Hdata 1.0b1 Hdata 1.0 Resolved closed
HDATA-16 Missing action in 6.4.2.2 when not including metadata Hdata 1.0b1 Hdata 1.0 Resolved closed
HDATA-15 DELETE on invalid or not-existing documentname URL should return 404 status code Hdata 1.0b1 Hdata 1.0 Resolved closed
HDATA-13 OPTIONS operation on not-existing baseURL should return 404 status code Hdata 1.0b1 Hdata 1.0 Resolved closed
HDATA-12 GET operation on baseURL/root.xml needs explicit MUST in the requirement Hdata 1.0b1 Hdata 1.0 Resolved closed
HDATA-11 6.3 baseURL/root.xml Hdata 1.0b1 Hdata 1.0 Resolved closed
HDATA-10 6.2 Operations on the Base URL Hdata 1.0b1 Hdata 1.0 Resolved closed
HDATA-19 Minor deletion or rewrite to PUT operation wording Hdata 1.0b1 Hdata 1.0 Resolved closed
HDATA-18 Wrong target context in 6.5.4 - change 'section' to 'document' Hdata 1.0b1 Hdata 1.0 Resolved closed
HDATA-17 Creating sub-secton incorrectly describes updating the root document Hdata 1.0b1 Hdata 1.0 Resolved closed
HDATA-14 GET operation on non-existing baseURL or sectionpath SHOULD return 404 status code Hdata 1.0b1 Hdata 1.0 Resolved closed
HDATA-9 Annex A: reference [1] is normative for this specification but there is no indication of how it can be obatined Hdata 1.0b1 Hdata 1.0 Resolved closed
HDATA-8 8.5 first line type RECOMMEDED Hdata 1.0b1 Hdata 1.0 Resolved closed

Issues Descriptions

Create a paragraph in section 6.5 clarifying how resource URL paths are constructed

  • Key: HDATA-48
  • Legacy Issue Number: 18291
  • Status: closed  
  • Source: LogMeIn, Inc ( Gerald Beuchelt)
  • Summary:

    Create a paragraph in section 6.5 clarifying how resource URL paths are constructed

  • Reported: Hdata 1.0b1 — Thu, 13 Dec 2012 05:00 GMT
  • Disposition: Resolved — Hdata 1.0
  • Disposition Summary:

    Added text in section 6.1.2.

  • Updated: Fri, 6 Mar 2015 23:16 GMT

Create a subsection in section 6.1.2 to identify forbidden keywords in paths for URLs

  • Key: HDATA-47
  • Legacy Issue Number: 18290
  • Status: closed  
  • Source: LogMeIn, Inc ( Gerald Beuchelt)
  • Summary:

    Create a subsection in section 6.1.2 to identify forbidden keywords in paths for URLs

  • Reported: Hdata 1.0b1 — Thu, 13 Dec 2012 05:00 GMT
  • Disposition: Resolved — Hdata 1.0
  • Disposition Summary:

    Added text in section 6.1.2

  • Updated: Fri, 6 Mar 2015 23:16 GMT

6.4 baseURL/sectionpath

  • Key: HDATA-46
  • Legacy Issue Number: 17235
  • Status: closed  
  • Source: MITRE ( Mr. Jason Mathews)
  • Summary:

    6.4.1 GET This operation MUST return an Atom 1.0 compliant feed of all section documents and child sections contained in this section.
    Status Code: 200

    The implied requirement here is following:
    If baseURL does not exist or no sectionpath of name sectionpath exists, the implementation MUST (SHOULD) return a HTTP status code 404.

    This would then be consistent with section 6.5.1 for an invalid/non-existing documentname in the URL.

  • Reported: Hdata 1.0b1 — Tue, 13 Mar 2012 04:00 GMT
  • Disposition: Resolved — Hdata 1.0
  • Disposition Summary:

    issue withdrawn by submitter, replaced by issue 17238

  • Updated: Fri, 6 Mar 2015 23:16 GMT

Revise current (20121004) JSON representation of Atom feed and data in section 6.1.2

  • Key: HDATA-43
  • Legacy Issue Number: 18221
  • Status: closed  
  • Source: LogMeIn, Inc ( Gerald Beuchelt)
  • Summary:

    revise current (20121004) JSON representation of Atom feed and data in section 6.1.2, and incorporate lessons-learned from FHIR implementation

  • Reported: Hdata 1.0b1 — Wed, 24 Oct 2012 04:00 GMT
  • Disposition: Resolved — Hdata 1.0
  • Disposition Summary:

    Updated Section 6.1.2 and added non-normative Annex C

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Conformance statement

  • Key: HDATA-42
  • Legacy Issue Number: 18139
  • Status: closed  
  • Source: LogMeIn, Inc ( Gerald Beuchelt)
  • Summary:
    • use baseURL/metadata to allow service information
    • provide current baseURL/conf as non-normative example
  • Reported: Hdata 1.0b1 — Fri, 5 Oct 2012 04:00 GMT
  • Disposition: Resolved — Hdata 1.0
  • Disposition Summary:

    Added the following text as section 6.3.2.

  • Updated: Fri, 6 Mar 2015 20:58 GMT

subscription push

  • Key: HDATA-41
  • Legacy Issue Number: 18138
  • Status: closed  
  • Source: LogMeIn, Inc ( Gerald Beuchelt)
  • Summary:
    • client pushes feed
    • enable "bulk" update
    • POST to Section (see 6.4.2.2)
  • Reported: Hdata 1.0b1 — Fri, 5 Oct 2012 04:00 GMT
  • Disposition: Resolved — Hdata 1.0
  • Disposition Summary:

    Add paragraph to section 6.4.2.2 that implements this function

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Represent DELETE in Atom: XML Fragment in Atom:Content

  • Key: HDATA-37
  • Legacy Issue Number: 18134
  • Status: closed  
  • Source: LogMeIn, Inc ( Gerald Beuchelt)
  • Summary:

    Represent DELETE in Atom: XML Fragment in Atom:Content

    • Needs to be for 410 resources, not for 404
  • Reported: Hdata 1.0b1 — Fri, 5 Oct 2012 04:00 GMT
  • Disposition: Resolved — Hdata 1.0
  • Disposition Summary:

    Add text to section 6.5.4 indicating that this SHOULD be done for SectionDocuments that are DELETED and return a 410.

  • Updated: Fri, 6 Mar 2015 20:58 GMT

mime type for format parameter (text/xml vs. xml)

  • Key: HDATA-36
  • Legacy Issue Number: 18133
  • Status: closed  
  • Source: LogMeIn, Inc ( Gerald Beuchelt)
  • Summary:

    mime type for format parameter (text/xml vs. xml)

    • exception for xml and json
    • MUST accept full MIME types
  • Reported: Hdata 1.0b1 — Fri, 5 Oct 2012 04:00 GMT
  • Disposition: Resolved — Hdata 1.0
  • Disposition Summary:

    Add text to section 6.1.2 (General Conventions and Considerations) to allow clients to use simplified media types and require server to support this.

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Change 6.5.3 to allow PUT creation of new documents to allow the client to suggest location. Same semantics as 6.4.2.2

  • Key: HDATA-45
  • Legacy Issue Number: 18227
  • Status: closed  
  • Source: LogMeIn, Inc ( Gerald Beuchelt)
  • Summary:

    Change 6.5.3 to allow PUT creation of new documents to allow the client to suggest location. Same semantics as 6.4.2.2, if conflict return 409

  • Reported: Hdata 1.0b1 — Wed, 24 Oct 2012 04:00 GMT
  • Disposition: Resolved — Hdata 1.0
  • Disposition Summary:

    Change section 6.5.3 to reflect updated semantics

  • Updated: Fri, 6 Mar 2015 20:58 GMT

search extensions (include as non-normative examples)

  • Key: HDATA-40
  • Legacy Issue Number: 18137
  • Status: closed  
  • Source: LogMeIn, Inc ( Gerald Beuchelt)
  • Summary:
    • $INCLUDE
    • others
  • Reported: Hdata 1.0b1 — Fri, 5 Oct 2012 04:00 GMT
  • Disposition: Resolved — Hdata 1.0
  • Disposition Summary:

    Add clarifying paragraph to section 6.6. on searching

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Atom feed link:rel needs to be version specific

  • Key: HDATA-39
  • Legacy Issue Number: 18136
  • Status: closed  
  • Source: LogMeIn, Inc ( Gerald Beuchelt)
  • Summary:
    • MUST support version specific retrieval of current version
    • MAY support version specific retrieval of older version
  • Reported: Hdata 1.0b1 — Fri, 5 Oct 2012 04:00 GMT
  • Disposition: Resolved — Hdata 1.0
  • Disposition Summary:

    Add text to the paragraphs on section Atom feed in section 6.4, and version-specific URLs for SectionDocuments in section 6.5.

  • Updated: Fri, 6 Mar 2015 20:58 GMT

discuss impact of deletion of resources/SectionDocuments onto the Section level Atom feed/JSON bundle to section 6.4.4

  • Key: HDATA-44
  • Legacy Issue Number: 18222
  • Status: closed  
  • Source: HL7 ( Mr. Grahame Grieve)
  • Summary:

    discuss impact of deletion of resources/SectionDocuments onto the Section level Atom feed/JSON bundle to section 6.4.4

  • Reported: Hdata 1.0b1 — Wed, 24 Oct 2012 04:00 GMT
  • Disposition: Resolved — Hdata 1.0
  • Disposition Summary:

    This should apply to section 6.4.1 – GET on baseURL/sectionpath.

    Added text clarifying the impact of DELETE of a document (as described in section 6.5.4).

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Inconsistent spelling for extensionId in parameter list for 6.2.2

  • Key: HDATA-35
  • Legacy Issue Number: 17579
  • Status: closed  
  • Source: MITRE ( Mr. Jason Mathews)
  • Summary:

    6.2.2 POST ­ Parameters:extensionID, path, name

    But the body of the section defines the 'extensionId' parameter with different spelling.

    This should be consistent with created sub-section as defined in 6.4.2.1 which uses extensionId in all occurrences.

    extensionID should be corrected and renamed to "extensionId".

  • Reported: Hdata 1.0b1 — Tue, 11 Sep 2012 04:00 GMT
  • Disposition: Resolved — Hdata 1.0
  • Disposition Summary:

    Make changes to 6.2.2

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Content override in two party update

  • Key: HDATA-38
  • Legacy Issue Number: 18135
  • Status: closed  
  • Source: LogMeIn, Inc ( Gerald Beuchelt)
  • Summary:

    Describe obligations and error codes around create/updates

    • Server can deny update request when update is incorrect
    • (HTTP PUT)
    • This may be best suited to be resolved at the FHIR specification level
  • Reported: Hdata 1.0b1 — Fri, 5 Oct 2012 04:00 GMT
  • Disposition: Resolved — Hdata 1.0
  • Disposition Summary:

    Clarification in section 6.1.2, “Incorrect Updates”

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Lack of a Normative References section

  • Key: HDATA-4
  • Legacy Issue Number: 16915
  • Status: closed  
  • Source: Adaptive ( Mr. Pete Rivett)
  • Summary:

    Lack of a Normative References section e.g. including Atom and other documents referenced as being required for an implementation

  • Reported: Hdata 1.0b1 — Thu, 15 Dec 2011 05:00 GMT
  • Disposition: Resolved — Hdata 1.0
  • Disposition Summary:

    Update Annex A – Normative References

  • Updated: Fri, 6 Mar 2015 20:58 GMT

7.1 line 2: “This pattern may be combined” – unclear what it may be combined with.

  • Key: HDATA-7
  • Legacy Issue Number: 16918
  • Status: closed  
  • Source: Adaptive ( Mr. Pete Rivett)
  • Summary:

    7.1 line 2: “This pattern may be combined” – unclear what it may be combined with.

  • Reported: Hdata 1.0b1 — Thu, 15 Dec 2011 05:00 GMT
  • Disposition: Resolved — Hdata 1.0
  • Disposition Summary:

    Clarify this sentence to reference operations in section 6 of the document; add clarification regarding potentially explicit exclusion.

  • Updated: Fri, 6 Mar 2015 20:58 GMT

6.1.1 penultimate sentence, typo “this documents”

  • Key: HDATA-6
  • Legacy Issue Number: 16917
  • Status: closed  
  • Source: Adaptive ( Mr. Pete Rivett)
  • Summary:

    6.1.1 penultimate sentence, typo “this documents”

  • Reported: Hdata 1.0b1 — Thu, 15 Dec 2011 05:00 GMT
  • Disposition: Resolved — Hdata 1.0
  • Disposition Summary:

    Corrected to “this document.”

  • Updated: Fri, 6 Mar 2015 20:58 GMT

RESTful vs. REST

  • Key: HDATA-3
  • Legacy Issue Number: 16914
  • Status: closed  
  • Source: Thematix Partners LLC ( Dr. Doug Tolbert)
  • Summary:

    Throughout the text of the RFC document, you refer to "RESTful" while the cover page uses the term "REST" in the title of the RFC. Please reconcile the use of these terms throughout the document.

  • Reported: Hdata 1.0b1 — Mon, 9 Jan 2012 05:00 GMT
  • Disposition: Resolved — Hdata 1.0
  • Disposition Summary:

    Replaced REST globally with RESTful

  • Updated: Fri, 6 Mar 2015 20:58 GMT

security negotiation through the use of custom HTTP headers

  • Key: HDATA-2
  • Legacy Issue Number: 18316
  • Status: open  
  • Source: LogMeIn, Inc ( Gerald Beuchelt)
  • Summary:

    We had identified a potential issue for a future hData RTF regarding the security negotiation through the use of custom HTTP headers. A future version of hData should use the WWW-Authenticate header instead of any X-hdata-* custom headers.

  • Reported: Hdata 1.0 — Thu, 13 Dec 2012 05:00 GMT
  • Updated: Fri, 6 Mar 2015 20:58 GMT

Section 3, 3rd definition: typo “is access”

  • Key: HDATA-5
  • Legacy Issue Number: 16916
  • Status: closed  
  • Source: Adaptive ( Mr. Pete Rivett)
  • Summary:

    Section 3, 3rd definition: typo “is access”

  • Reported: Hdata 1.0b1 — Thu, 15 Dec 2011 05:00 GMT
  • Disposition: Resolved — Hdata 1.0
  • Disposition Summary:

    Corrected to “is accessed”.

  • Updated: Fri, 6 Mar 2015 20:58 GMT

separate the general RESTful pattern use from the hData specific features

  • Key: HDATA-1
  • Legacy Issue Number: 17375
  • Status: open  
  • Source: Anonymous
  • Summary:

    The specification as it is describes a particular pattern of use
    that includes
    aspects that are specific to hData. It would help us greatly to separate the
    general RESTful pattern use from the hData specific features; this way, we could
    reference the specification directly and it would be clear how we
    could conform to it.

  • Reported: Hdata 1.0b1 — Sun, 20 May 2012 04:00 GMT
  • Updated: Fri, 6 Mar 2015 20:58 GMT

Metadata Communication

  • Key: HDATA-26
  • Legacy Issue Number: 17381
  • Status: closed  
  • Source: HL7 ( Mr. Grahame Grieve)
  • Summary:

    Section 6.2.5 and 6.3 can be combined into a single way to query for
    metadata about
    the service. The additional HTTP headers created in 6.2.5 are
    problematic for some
    clients and/or servers to implement. As such the OPTION operation on
    the (baseURL)
    could return a body with a XML document instead, which contains the information
    contained in the 6.2.5. headers, as well at the root.xml manifest.
    This would reduce the
    number of roundtrips significantly. There should also be a way to
    access this information
    without using the OPTIONS command to enable the same information to be available
    via a <a href=""> link in a web page.

  • Reported: Hdata 1.0b1 — Sun, 20 May 2012 04:00 GMT
  • Disposition: Resolved — Hdata 1.0
  • Disposition Summary:

    Partially accept. Make OPTIONS on base URL a SHOULD (instead of MUST), and add baseURL/metadata as a reserved URL. Make that document available at baseURL/metadata and also allow sending with OPTIONS body.

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Intermediaries Consideration

  • Key: HDATA-25
  • Legacy Issue Number: 17380
  • Status: closed  
  • Source: HL7 ( Mr. Grahame Grieve)
  • Summary:

    The HTTP protocol may be routed through an HTTP proxy such as squid.
    Such proxies are transparent to the applications, though implementors
    should be alert to the effects of rogue caching.

    Interface engines may also be placed between the consumer and the
    provider; these differ from proxies because they actively alter the
    content and/or destination of the HTTP exchange and are not bound the
    rules that apply to HTTP proxies. Such agents are allowed, but must
    mark the http header to assist with troubleshooting.

    Any agent that modifies an HTTP request or Response content other than
    under the rules for HTTP proxie must add a stamp to the HTTP headers
    like this:

    request-modified-[identity]: [purpose]
    response-modified-[identity]: [purpose]

    The identity must a single token defined by the administrator of the
    agent that will sufficiently identify the agent in the context of use.
    The header must specify the agents purpose in modifying the content.
    End point systems must not use this header for any purpose; it's aim
    is to assist with system troubleshooting.

    ."

  • Reported: Hdata 1.0b1 — Sun, 20 May 2012 04:00 GMT
  • Disposition: Resolved — Hdata 1.0
  • Disposition Summary:

    This concern is added as another General Consideration to section 6.1.2.

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Simple search

  • Key: HDATA-24
  • Legacy Issue Number: 17379
  • Status: closed  
  • Source: HL7 ( Mr. Grahame Grieve)
  • Summary:

    To support simple searches over Sections and the entire record, for
    the section 6.2 and
    6.4, the following URL structure is reserved:

    5.1. (baseURL)/search?(queryParameter)

    This allows a search over the entire record. The (queryParameter) can
    be arbitrary,
    but it is RECOMMENDED to use HTTP form-encoding style key/value parameters.
    The server returns the results of the query in the form of an Atom
    feed, with each Entry
    representing a search result.

    5.2. (baseURL)/(sectionPath)/search?(queryParameter)

    The semantics for this query are identical to the one in 4.1., but the
    scope is limited to
    the section described by the sectionPath.

  • Reported: Hdata 1.0b1 — Sun, 20 May 2012 04:00 GMT
  • Disposition: Resolved — Hdata 1.0
  • Disposition Summary:

    Created new section 6.6 to implement requested capability.
    Added section 6.3.3

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Validation service

  • Key: HDATA-23
  • Legacy Issue Number: 17378
  • Status: closed  
  • Source: HL7 ( Mr. Grahame Grieve)
  • Summary:

    Similar to the version-aware resource structure, the following URL for
    sectionDocuments is reserved:

    (baseURL)/(sectionPath)/(sectionDocument)/validate/

    This allows a client to ask the server whether the attached POSTed
    content would be
    acceptable as a PUT. By this means that client can
    (a) validate business logic during testing concerning correct content
    (b) implement a lite two-phase commit alternative that reduces the
    chance of partial success of multi-resource operations.

    The second functionality overlaps a little with existing functionality
    around safe commit,
    though what is there now solves a different problem. From the point of
    view of FHIR, the
    first is at least as important: a real world way to test content
    without only having to rely
    on claims.

  • Reported: Hdata 1.0b1 — Sun, 20 May 2012 04:00 GMT
  • Disposition: Resolved — Hdata 1.0
  • Disposition Summary:

    Added text defining this mechanism to section 6.5.

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Comments on Section 9

  • Key: HDATA-33
  • Legacy Issue Number: 17388
  • Status: closed  
  • Source: THALES ( Hugues Vincent)
  • Summary:

    This section must be noted as non-normative (in the title)

    • Section 9.2 - in the table: replace "(version 1.0.1...)" with the reference [12]
  • Reported: Hdata 1.0b1 — Mon, 21 May 2012 04:00 GMT
  • Disposition: Resolved — Hdata 1.0
  • Disposition Summary:

    Update the title and reference in the table

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Comments on Section 8

  • Key: HDATA-32
  • Legacy Issue Number: 17387
  • Status: closed  
  • Source: THALES ( Hugues Vincent)
  • Summary:

    Section 8.1 - 2nd paragraph: sentence not parsable: "If the custom security mechanism The URIs..."

    • Bullet 2: should be "URI or none" on account of the HTTP Transport Security
    • Bullet 5: "State Diagram": what is the format of this UML state diagram? XMI?
    • Section 8.3 - last sentence: which "template" are you speaking of?
    • Section 8.4 and 8.5: these sections should be noted as informative or non-normative (in their title)
  • Reported: Hdata 1.0b1 — Mon, 21 May 2012 04:00 GMT
  • Disposition: Resolved — Hdata 1.0
  • Disposition Summary:

    : Incorporated suggested changes for 8.1, 8.4, and 8.5. The reference in section 8.3 was broken and should have pointed back to section 8.1. An additional clarification was added to the 2nd paragraph in section 8.1.

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Comments on Section 6

  • Key: HDATA-30
  • Legacy Issue Number: 17385
  • Status: closed  
  • Source: THALES ( Hugues Vincent)
  • Summary:

    The Get/Put/Delete/Post subsection are not allways listed in the same order, which doesn't ease the reading and the finding of information.

    • Section 6.2.5: add a reference to the section 8 which is also speaking about this point.
    • Section 6.4.1: ", is RECOMMENDED" -> ", it is RECOMMENDED"
  • Reported: Hdata 1.0b1 — Mon, 21 May 2012 04:00 GMT
  • Disposition: Resolved — Hdata 1.0
  • Disposition Summary:

    Accepted the request to swap 6.5.2 and 6.5.3.

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Comments on Section 3

  • Key: HDATA-29
  • Legacy Issue Number: 17384
  • Status: closed  
  • Source: THALES ( Hugues Vincent)
  • Summary:

    In the paragraph "hData REST Binding for RLUS": "... HRF specification is access..." -> is accessed

    • The paragraph "Semantic signifier" speaks about "The UML diagram below..." while there is no UML diagram. If you decided to add such a UML diagram, the matching XMI would be necessary.
  • Reported: Hdata 1.0b1 — Mon, 21 May 2012 04:00 GMT
  • Disposition: Resolved — Hdata 1.0
  • Disposition Summary:

    Corrected typo. Removed sentence for Semantic Signifier.

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Comments on Section

  • Key: HDATA-28
  • Legacy Issue Number: 17383
  • Status: closed  
  • Source: THALES ( Hugues Vincent)
  • Summary:

    How is this wpecification supposed to evolve wrt the version of OMG's RLUS and HL7's RLUS? I believe this should be a bit explained in section 1.

    • Complex operations as well as Security need to be also introduced in this section.
    • Last paragraph: add reference [12] when speaking of the OMG RLUS PIM.
  • Reported: Hdata 1.0b1 — Mon, 21 May 2012 04:00 GMT
  • Disposition: Resolved — Hdata 1.0
  • Disposition Summary:

    Add clarifying paragraph at the end of section 1

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Pattern for reliability

  • Key: HDATA-31
  • Legacy Issue Number: 17386
  • Status: closed  
  • Source: THALES ( Hugues Vincent)
  • Summary:

    Section 7.1: in which way this pattern is "reliable"? A clear explanation of which risks are covered is needed here.

  • Reported: Hdata 1.0b1 — Mon, 21 May 2012 04:00 GMT
  • Disposition: Resolved — Hdata 1.0
  • Disposition Summary:

    Expanded the introduction in 7.1 to address concerns

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Need clarificaton for server response to client request using the Max-Forwards header field

  • Key: HDATA-34
  • Legacy Issue Number: 17566
  • Status: closed  
  • Source: MITRE ( Mr. Jason Mathews)
  • Summary:

    Section 6.2.5 states "client MUST NOT use the Max-Forward header when requesting the security mechanisms for a given HDR" but no action is defined for the server.

    If Max-Forwards field is truly not permitted on the OPTION operation then recommend adding expected the server action. Suggest to return a 403 Forbidden status code with optional message "Request cannot include Max-Forwards header field".

    References:
    Max-forwards usage:
    http://www.w3.org/Protocols/rfc2616/rfc2616-sec9.html#sec9.2

    HTTP status codes
    http://www.w3.org/Protocols/rfc2616/rfc2616-sec10.html

  • Reported: Hdata 1.0b1 — Mon, 27 Aug 2012 04:00 GMT
  • Disposition: Resolved — Hdata 1.0
  • Disposition Summary:

    Change section 6.2.5 accordingly

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Alternate content negotiation

  • Key: HDATA-22
  • Legacy Issue Number: 17377
  • Status: closed  
  • Source: HL7 ( Mr. Grahame Grieve)
  • Summary:

    Throughout section 6. of the hData spec, the server should accept the
    following HTTP
    query string to perform alternate media type negotiation:

    (URL)?format=(mediaType)

    where (mediaType) MUST be a valid Internet Media type. This explicit content
    negotiation takes precedence over the Accept-Header negotiation. The
    reason why this
    is needed is the unreliable support of the Accept-Header mechanism in
    clients, particularly
    in older development stacks. While we strongly encourage adoption of
    the content negotiation
    framework per the HTTP specification, we wish to be as inclusive as possible

  • Reported: Hdata 1.0b1 — Sun, 20 May 2012 04:00 GMT
  • Disposition: Resolved — Hdata 1.0
  • Disposition Summary:

    Added text defining this mechanism to section 6.1.2

  • Updated: Fri, 6 Mar 2015 20:58 GMT

no clear conformance point

  • Key: HDATA-27
  • Legacy Issue Number: 17382
  • Status: closed  
  • Source: THALES ( Hugues Vincent)
  • Summary:

    There is no clear conformance point but the understatement made by the use of the RFC2119. I propose to rename section 4 "Conformance point" and to add "Implementations must support the entire mapping" before the description of keywords.

  • Reported: Hdata 1.0b1 — Mon, 21 May 2012 04:00 GMT
  • Disposition: Resolved — Hdata 1.0
  • Disposition Summary:

    Section 4 modified as suggested

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Enable the use of version-aware resource URLs

  • Key: HDATA-21
  • Legacy Issue Number: 17376
  • Status: closed  
  • Source: HL7 ( Mr. Grahame Grieve)
  • Summary:

    Most of the changes requested in this section apply to 6.5 of the
    hData specification.
    FHIR will need to be able to access different versions of a resource.
    To enable this most
    effectively, the spec should support the following URL extensions on
    SectionDocuments
    for GET, PUT, and POST operations:

    (resourceURL) = (baseURL)/(sectionPath)/(sectionDocument)
    (versionAwareResourceURL) = (resource)/history/(version-id)

    where (version-id) is any unique string. Also, a GET on the (resourceURL) should
    return the representation of the resource in the HTTP body, a status
    code of 200, and
    a Content-Location header containing the (versionAwareResourceURL) of
    the current
    version of that resource.

    If the resource was deleted with a DELETE, the service SHOULD return a
    HTTP status
    code 410, with no body. However it MAY return a 404 as alternative.

    To enable safe updates, the following process MUST be used:

    • The client reads obtains the representation of the current version
    by performing a GET
    on the (resourceURL). This contains the reference to (versionAwareResourceURL).
    • The client makes the necessary changes to the state.
    • The client MUST then PUT the updates representation to the
    (resourceURL) and quote the versionAwareResourceURL in the Content-Location
    header of the PUT operation.
    • If the (versionAwareResourceURL) provided by the client is the
    current version, the
    server accepts the representation and persists the change, and returns a HTTP
    response with
    • a status code of 202 ok,
    • a Content-Location header with the (versionAwareResourceURL) of the new

    version, and
    • the representation of the new version of the resource in the
    • If the (versionAwareResourceURL) represents no longer the current version, the
    server MUST return a HTTP response with status code 412, a Content-Location
    header with the new (versionAwareResourceURL), and a representation of
    the latest
    version of the resource.

  • Reported: Hdata 1.0b1 — Sun, 20 May 2012 04:00 GMT
  • Disposition: Resolved — Hdata 1.0
  • Disposition Summary:

    Added version-aware scheme to 6.5, edited 6.5.1 and 6.5.3 (formerly 6.5.2) to address concern

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Section 6.5.1 should specify allowing negotiation through HTTP Accept headers

  • Key: HDATA-20
  • Legacy Issue Number: 17348
  • Status: closed  
  • Source: MITRE ( Mr. Jason Mathews)
  • Summary:

    Section 6.5.1 should specify that content negotiation through HTTP Accept headers is possible, and indicate how this interacts with the metadata specified in the HL7 spec.

  • Reported: Hdata 1.0b1 — Thu, 3 May 2012 04:00 GMT
  • Disposition: Resolved — Hdata 1.0
  • Disposition Summary:

    Accepted, but this was added to section 6.1.2, since this may apply to all resources. Issue 17377 is also fixed in 6.1.2.

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Missing action in 6.4.2.2 when not including metadata

  • Key: HDATA-16
  • Legacy Issue Number: 17271
  • Status: closed  
  • Source: MITRE ( Mr. Jason Mathews)
  • Summary:

    Section 6.4.2.2 (Adding new document) describes the case when including metadata in POST operation using
    "multipart/form-data", however, it does not describe when not including metadata.

    Here's text for the implied requirement:

    If POST does not include metadata then MUST POST with a Content Type conforming to the media type of the section. The body of the POST MUST contain the document of the new document. Document metadata in this case MUST be computed from the new document.

    This text or something like it must be inserted in this context:
    "It is to be treated as informational, since the service MUST compute the valid new metadata based on the requirements found in the HRF specification <INSERT HERE>
    The content media type MUST conform..."

  • Reported: Hdata 1.0b1 — Mon, 26 Mar 2012 04:00 GMT
  • Disposition: Resolved — Hdata 1.0
  • Disposition Summary:

    Added: “If POST does not include metadata then MUST POST with a Content Type conforming to the media type of the section. The body of the POST MUST contain the document of the new document. Document metadata in this case MUST be created by the system, based on instructions in the hData Content Profile applying to the system.”

  • Updated: Fri, 6 Mar 2015 20:58 GMT

DELETE on invalid or not-existing documentname URL should return 404 status code

  • Key: HDATA-15
  • Legacy Issue Number: 17239
  • Status: closed  
  • Source: MITRE ( Mr. Jason Mathews)
  • Summary:

    Context: 6.5.4 DELETE baseURL/sectionpath/documentname

    The implied requirement here is the following, which should be appended to the section to make it consistent with 6.4.4 and 6.5.1:

    If baseURL, sectionpath, or target document name does NOT exist, the implementation SHOULD return a 404 - Not found HTTP status code.

  • Reported: Hdata 1.0b1 — Tue, 13 Mar 2012 04:00 GMT
  • Disposition: Resolved — Hdata 1.0
  • Disposition Summary:

    Changed as suggested by submitter

  • Updated: Fri, 6 Mar 2015 20:58 GMT

OPTIONS operation on not-existing baseURL should return 404 status code

  • Key: HDATA-13
  • Legacy Issue Number: 17237
  • Status: closed  
  • Source: MITRE ( Mr. Jason Mathews)
  • Summary:

    The requirements reads as "OPTIONS on HDR baseURL MUST return 200 status".

    The implied requirement is the following which should be appended to this requirement:

    If there is no HDR at the base URL, the server SHOULD return a 404 - Not found status code.

    This would then be consistent with requirement in section 6.2.1 for the GET operation.

  • Reported: Hdata 1.0b1 — Tue, 13 Mar 2012 04:00 GMT
  • Disposition: Resolved — Hdata 1.0
  • Disposition Summary:

    Changed in section 6.2.5 to reflect the fact that this only applies to HDR records.

  • Updated: Fri, 6 Mar 2015 20:58 GMT

GET operation on baseURL/root.xml needs explicit MUST in the requirement

  • Key: HDATA-12
  • Legacy Issue Number: 17236
  • Status: closed  
  • Source: MITRE ( Mr. Jason Mathews)
  • Summary:

    The requirements reads as "This operation returns an XML representation of the current root document, as defined by the HRF specification."

    It can be inferred from this requirement that this is an implied “SHALL” or “MUST” mandatory requirement not an implied SHOULD/RECOMMENDED.

    Likewise, not defined if the baseURL does not exist, which should return 404 status code as done with similar HTTP operations. This would then be consistent with requirement in section 6.2.

    Revised requirement:

    This operation MUST return an XML representation of the current root document, as defined by the HRF specification.
    If there is no HDR at the base URL, the server SHOULD return a 404 - Not found status code.

  • Reported: Hdata 1.0b1 — Tue, 13 Mar 2012 04:00 GMT
  • Disposition: Resolved — Hdata 1.0
  • Disposition Summary:

    Resolved with 17234.

  • Updated: Fri, 6 Mar 2015 20:58 GMT

6.3 baseURL/root.xml

  • Key: HDATA-11
  • Legacy Issue Number: 17234
  • Status: closed  
  • Source: MITRE ( Mr. Jason Mathews)
  • Summary:

    6.3.1 GET

    This operation returns an XML representation of the current root document, as defined by the HRF specification.

    Status Code: 200

    It can be inferred from this requirement that this is an implied “SHALL” or “MUST” mandatory requirement not an implied SHOULD/RECOMMENDED.
    This implies the HTTP response contentType is text/xml or application/xml and the target namespace in the returned document ishttp://projecthdata.org/hdata/schemas/2009/06/core as defined by the HRF spec.
    Likewise, not defined if the baseURL does not exist, which should return 404 status code as done with similar HTTP operations.

    Recommend rewriting this requirement as follows:
    6.3.1 GET

    This operation MUST return an XML representation of the current root document, as defined by the HRF specification.
    If there is no HDR at the base URL, the server SHOULD return a 404 - Not found status code.

    Status Code: 200, 404

  • Reported: Hdata 1.0b1 — Tue, 13 Mar 2012 04:00 GMT
  • Disposition: Resolved — Hdata 1.0
  • Disposition Summary:

    Rewritten as recommended by submitter. Note that due to renumbering, this section is now 6.3.1.1.

  • Updated: Fri, 6 Mar 2015 20:58 GMT

6.2 Operations on the Base URL

  • Key: HDATA-10
  • Legacy Issue Number: 17233
  • Status: closed  
  • Source: MITRE ( Mr. Jason Mathews)
  • Summary:

    6.2.5 OPTIONS
    OPTIONS on HDR baseURL MUST return 200 status

    The implied requirement here is following:
    If there is no HDR at the base URL, the server SHOULD return a 404 - Not found status code.

    This would then be consistent with requirement in section 6.2.1 for GET operation.

  • Reported: Hdata 1.0b1 — Tue, 13 Mar 2012 04:00 GMT
  • Disposition: Resolved — Hdata 1.0
  • Disposition Summary:

    Duplicate of Issue 17237, with exception of adding 404. Added the 404 error to address this.

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Minor deletion or rewrite to PUT operation wording

  • Key: HDATA-19
  • Legacy Issue Number: 17313
  • Status: closed  
  • Source: MITRE ( Mr. Jason Mathews)
  • Summary:

    Context:
    6.5 baseURL/sectionpath/documentname
    6.5.2 PUT

    The text "If the request is successful, the new section document MUST show up in the document feed for the section" is not applicable for a document update since it's not a new document but an update.

    This is text verbatim from section 6.4.2.2 [Add new document].

    The text could be deleted or reworded to something like this:

    "If the request is successful, the updated section document MUST [continue to] show up in the document feed for the section".

  • Reported: Hdata 1.0b1 — Mon, 16 Apr 2012 04:00 GMT
  • Disposition: Resolved — Hdata 1.0
  • Disposition Summary:

    Changed as suggested by submitter. Note that this applied to the new section 6.5.3, since it was exchanged with 6.5.2.

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Wrong target context in 6.5.4 - change 'section' to 'document'

  • Key: HDATA-18
  • Legacy Issue Number: 17308
  • Status: closed  
  • Source: MITRE ( Mr. Jason Mathews)
  • Summary:

    Context:
    6.5 baseURL/sectionpath/documentname
    6.5.4 DELETE

    Text: Future requests to the section URL MAY return a status code of 410, unless the record is restored.

    "section" here should be changed to "document" because that is the context here.

    Also for clarification does future request mean only GET requests or does it include any/all operations on the document

    { POST, PUT, DELETE, etc. }

  • Reported: Hdata 1.0b1 — Fri, 13 Apr 2012 04:00 GMT
  • Disposition: Resolved — Hdata 1.0
  • Disposition Summary:

    The issue is valid and a change was made to address the concern

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Creating sub-secton incorrectly describes updating the root document

  • Key: HDATA-17
  • Legacy Issue Number: 17287
  • Status: closed  
  • Source: MITRE ( Mr. Jason Mathews)
  • Summary:

    Context:
    6.4 baseURL/sectionpath
    6.4.2.1 Add new section

    OLD text: When creating the section resource, the server MUST update the root document: in the node of the parent section a new child node must be inserted.

    This is the same text copied verbatim from section 6.2.2 which describes creating a new Section at the root of the document: "when creating the section resource, the server MUST update the root document: in the node of the parent section a new child node must be inserted" but in the context of creating a sub-section this is incorrect.

    The correct rewording should be:

    NEW: When creating the sub-section resource, the server MUST update the Atom 1.0 [3] compliant feed for the parent section: a new child node must be inserted as an entry in the Atom content with a link to the new section.

  • Reported: Hdata 1.0b1 — Fri, 30 Mar 2012 04:00 GMT
  • Disposition: Resolved — Hdata 1.0
  • Disposition Summary:

    The suggested update to the parent section’s Atom feed is correct. At the same time, the root document must also be updated to reflect the changed sectional outlay. The suggested text above is added to the paragraph, but does not replace it.

  • Updated: Fri, 6 Mar 2015 20:58 GMT

GET operation on non-existing baseURL or sectionpath SHOULD return 404 status code

  • Key: HDATA-14
  • Legacy Issue Number: 17238
  • Status: closed  
  • Source: MITRE ( Mr. Jason Mathews)
  • Summary:

    6.4.1 defines a GET with a 200 for success but doesn't address the not found case as defined in other GET operations (e.g. 6.2.1 and 6.5.1)

    The implied requirement here is the following, which should be added to the section:

    If baseURL does not exist or no sectionpath of name sectionpath exists, the implementation SHOULD (or MUST) return a HTTP status code 404.

    This would then be consistent with section 6.5.1 for an invalid/non-existing documentname in the URL

  • Reported: Hdata 1.0b1 — Tue, 13 Mar 2012 04:00 GMT
  • Disposition: Resolved — Hdata 1.0
  • Disposition Summary:

    Changed as suggested by submitter

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Annex A: reference [1] is normative for this specification but there is no indication of how it can be obatined

  • Key: HDATA-9
  • Legacy Issue Number: 16920
  • Status: closed  
  • Source: Adaptive ( Mr. Pete Rivett)
  • Summary:

    Annex A: reference [1] is normative for this specification but there is no indication of how it can be obatined

  • Reported: Hdata 1.0b1 — Thu, 15 Dec 2011 05:00 GMT
  • Disposition: Resolved — Hdata 1.0
  • Disposition Summary:

    Added reference on how to obtain HRF DSTU

  • Updated: Fri, 6 Mar 2015 20:58 GMT

8.5 first line type RECOMMEDED

  • Key: HDATA-8
  • Legacy Issue Number: 16919
  • Status: closed  
  • Source: Adaptive ( Mr. Pete Rivett)
  • Summary:

    8.5 first line type RECOMMEDED

  • Reported: Hdata 1.0b1 — Thu, 15 Dec 2011 05:00 GMT
  • Disposition: Resolved — Hdata 1.0
  • Disposition Summary:

    Corrected to RECOMMENDED. Note: this was already corrected in the Beta 1 version

  • Updated: Fri, 6 Mar 2015 20:58 GMT