3 ms·

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

by 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.

by deno 15y ago

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.