[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: XRDS media type
XRD v1.0 CD02 defines the “application/xrd+xml” media type.
Presumably this can be used when the content is an <XRD> element.
The doc also defines an <XRDS> element.
Is the same media type supposed to be used when the content is an <XRDS> element?
I notice there is some work (outside OASIS) on “XRD Provisioning” (http://xrdprovisioning.net/).
Draft 01 of that work reuses “application/xrd+xml” when the content is a <Link> element.
This must be wrong.
Atom [RFC 4287] defines “application/atom+xml” for both <atom:entry> and <atom:feed> documents.
I suspect that is now considered a poor (but irreversible) choice.
The subsequent Atom Publishing Protocol [RFC 5023, section 12] defines a “type” parameter to go with the media type to distinguish the two type of document: “application/atom+xml;type=entry” and “application/atom+xml;type=feed”.
The APP spec says:
“The Atom Syndication Format [RFC4287] defines the "application/
atom+xml" media type to identify both Atom Feed and Atom Entry
Documents. Implementation experience has demonstrated that Atom Feed
and Entry Documents can have different processing models and that
there are situations where they need to be differentiated. This
specification defines a "type" parameter used to differentiate the
two types of Atom documents.”
An <atom:feed> is basically a collection of <atom:entry>s, hence the strong analogy to <XRDS> and <XRD>.
My suggestions, from most preferred to least:
1. Define separate media types for <XRDS> and <XRD> -- I suspect it will be helpful in the long run (as per Atom/APP experience).
2. Add a sentence to the spec explicitly stating that the “application/xrd+xml” media type can be used for both <XRDS> and <XRD>.
3. Wait until it is needed then define a type parameter as per APP.