ordering-relationships

hhware · hhware · commit 67ca27a5ab07 · 2015-05-21T00:09:20.000-05:00
diff --git a/format/index.md b/format/index.md
@@ -297,6 +297,12 @@ relationship URLs.
 If present, a *related resource URL* **MUST** be a valid URL, even if the
 relationship isn't currently associated with any target resources.
 
+> Note: The spec does not impart meaning to order of resource identifier 
+objects in linkage arrays of to-many relationships, although implementations
+may do that. Arrays of resource identifier objects may represent ordered
+or unordered relationships, and both types can be mixed in one response
+object.
+
 For example, the following article is associated with an `author`:
 
 ```javascript
@@ -1453,8 +1459,8 @@ Accept: application/vnd.api+json
 
 If a client makes a `POST` request to a *relationship URL*, the server
 **MUST** append the specified members to the relationship using set
-semantics. This means that if a given `type` and `id` is already in the
-relationship, the server **MUST NOT** add it again.
+semantics (ordered or unordered). This means that if a given `type` and 
+`id` is already in the relationship, the server **MUST NOT** add it again.
 
 > Note: This matches the semantics of databases that use foreign keys for
 has-many relationships. Document-based storage should check the has-many
