3 ms·

Reading this leaves me troubled. Why not the XLink vocabulary, for instance? I can understand something like this appearing for JSON if only so that people ha

Reading this leaves me troubled. Why not the XLink vocabulary, for instance? I can understand something like this appearing for JSON if only so that people have an intrametalinguistic transition path for their JSON APIs, but letting so much existing work on interoperable XML representations fall by the wayside could be unfortunate. Did you actually register the media types? “Any and all elements are legal in a HAL representation provided they do not conflict with HAL's reserved elements.” If I'm reading this right: please, please, no. Not in XML. Allocate a namespace URI and use it. Let's not start down the path of everyone having to watch out for everyone else's element names again. The idea of identifying multiple packed related resources (which could otherwise be top-level resources) in the same document is interesting. I don't immediately recall specific prior specifications there, but I'd definitely want to go through the W3C site with a fine-toothed comb to check. E.g., Atom feeds already can embed XML fragments of almost any other type (though most commonly XHTML) as entry content; there may be some evolution of that available.

AffableSpatula 15y ago
Might be worth exploring if re-using stuff like XLink makes sense and is within keeping of the objective to keep things simple. Probably better to discuss that on the google group than here, feel free to join and raise it there. At the moment, it's registered with IANA as application/vnd.hal+xml, although I don't think it makes a huge difference either way at this point time. Element collision is not a big deal as clients should be determining element semantics on a per-resource basis and - importantly - in the context of the link relation leading to it (from either a resource or a link). You will find similarity with other media types like atom and rdf. Basically, it's designed to be more generic than atom and less convoluted than RDF.
deno 15y ago
YAML specifies standard way of including multiple documents in a single stream/file. With XML (assuming XSD-compatible parser), you can always extend the NS and have several documents in a single container (thus single stream/file), but I don't see how that would be preferable to just using MIME/Multipart.
- premchai21 15y ago
  MIME multipart is pretty good in and of itself, and in particular can represent a larger space of content types well. I'm trying to imagine how this interacts with things like URI fragment identifiers, though. MIME has Content-ID, but that's defined to be a msg-id, which doesn't help much. xml:id might be more effective in a sense, but then you run into the internal collision problem again. Implementationally, hooking up an extra MIME layer is a lot more cumbersome than it should be. This is theoretically a transient characteristic, but I have the creeping feeling that that will destroy any attempts to use MIME for this purpose regardless.
  - deno 15y ago
    Well, yes, if the content is inter-connected this is more tricky. Xml:id assumes unique identifiers within scope, and with multiple documents that would require a global scope, something that is not standardized and problematic (it'd require either using UUIDs as IDs or keeping track of uniqueness in some other way). I think a better solution would be to use XLink. Assuming each document has its own canonical link, this is then straightforward: 1. Make sure each XML document within MIME/Multipart container includes <link rel="canonical" href="uri:…"/> 2. Each document in a MIME/Multipart container should refer to other documents using xlink, i.e. unique URL with a part identifying specific fragment using XPath (which can then use xml:id in a local scope). Now, depending on the client following scenarios are possible: 1. Naïve: Client will perform redundant requests, but will cache documents in containers, resulting in several HTTP(304) responses. 2. Smart: Client will notice that referred documents are contained in a multipart MIME message and will use local versions. As a bonus, this approach is not dependant on MIME in any way — it will work just as well with, for example, a ZIP archive.

AffableSpatula 15y ago

Might be worth exploring if re-using stuff like XLink makes sense and is within keeping of the objective to keep things simple. Probably better to discuss that on the google group than here, feel free to join and raise it there. At the moment, it's registered with IANA as application/vnd.hal+xml, although I don't think it makes a huge difference either way at this point time. Element collision is not a big deal as clients should be determining element semantics on a per-resource basis and - importantly - in the context of the link relation leading to it (from either a resource or a link). You will find similarity with other media types like atom and rdf. Basically, it's designed to be more generic than atom and less convoluted than RDF.

deno 15y ago

YAML specifies standard way of including multiple documents in a single stream/file. With XML (assuming XSD-compatible parser), you can always extend the NS and have several documents in a single container (thus single stream/file), but I don't see how that would be preferable to just using MIME/Multipart.

premchai21 15y ago
MIME multipart is pretty good in and of itself, and in particular can represent a larger space of content types well. I'm trying to imagine how this interacts with things like URI fragment identifiers, though. MIME has Content-ID, but that's defined to be a msg-id, which doesn't help much. xml:id might be more effective in a sense, but then you run into the internal collision problem again. Implementationally, hooking up an extra MIME layer is a lot more cumbersome than it should be. This is theoretically a transient characteristic, but I have the creeping feeling that that will destroy any attempts to use MIME for this purpose regardless.
- deno 15y ago
  Well, yes, if the content is inter-connected this is more tricky. Xml:id assumes unique identifiers within scope, and with multiple documents that would require a global scope, something that is not standardized and problematic (it'd require either using UUIDs as IDs or keeping track of uniqueness in some other way). I think a better solution would be to use XLink. Assuming each document has its own canonical link, this is then straightforward: 1. Make sure each XML document within MIME/Multipart container includes <link rel="canonical" href="uri:…"/> 2. Each document in a MIME/Multipart container should refer to other documents using xlink, i.e. unique URL with a part identifying specific fragment using XPath (which can then use xml:id in a local scope). Now, depending on the client following scenarios are possible: 1. Naïve: Client will perform redundant requests, but will cache documents in containers, resulting in several HTTP(304) responses. 2. Smart: Client will notice that referred documents are contained in a multipart MIME message and will use local versions. As a bonus, this approach is not dependant on MIME in any way — it will work just as well with, for example, a ZIP archive.