In apps, we've had the practice of defining different MIME types for
different kinds of XML-formatted data. A custom MIME type can often
tell you much more than just what the formatting is, of course. This
is most frequently seen in documents that might be sent over HTTP,
where filtering or dispatching (to a Web application, for example) can
possibly be done on the MIME type alone. However there's always the
fallback to application/xml which may or may not be allowed depending
on the context. E.g. the W3C says that XHTML documents SHOULD be
given the content type "application/html+xml" when returned to
clients, although of course a Web server could return other XML
documents as application/xml.
The convention is to put "+xml" on the end of the MIME type -- I don't
know if it's very common for implementations to use that convention to
tell that the document is in XML even when the specific MIME type is
not known.
Whether this approach would be worth it in CMS as well, I can't tell.
Looking at RFC2984, OIDs seem to be about cryptographic functions, not
content objects. What am I missing?
Lisa
On Apr 4, 2008, at 6:54 AM, Russ Housley wrote:
I have received a request to assign an Object Identifier (OID) to be
used as a content type for XML objects. The idea is that one would
look inside the XML object to determine the type of XML object that
is being carried inside CMS.
Is this the right thing to do?
Would it be better to have a different content type for each XML
object?
Would it be better to use id-data?
Russ