Sam Ruby wrote:
Robert Sayre wrote:
> >> If I am conflating validity with media types, then so is the XML >> specification. > > > I don't understand that, could you explain?
See the XML specification section F.2 [1]. It is quite possible for an XML document to be valid if served with media type application/xml, but for the same document to be valid if served with a media type of text/xml.
Not a situation that I particularly care for. And it is widely ignored. But that's what the specs say.
(the following is more irritating than my actual personality...)
The XML specification defines validity in terms of DTDs.
The XML specification defines violation of a well-formedness constraint as a fatal error.
The XML specification defines an illegal byte sequence during decoding as a fatal error.
It is quite possible for an XML document to be served with an incorrect media type and remain well-formed and valid.
Atom documents are well-formed, but not valid, according to the XML spec. http://www.w3.org/TR/REC-xml/#sec-prolog-dtd
>> If the validator does not look to the spec for guidance, where >> should it look? >> >> If somebody can answer my questions, I would appreciate it.. > > > I think the spec should cover Atom documents identified with the > Atom media type. Other types are undefined.
If the behavior is undefined, then people should not expect interoperability. If the only use case for atom:info is based on depending on something that is undefined, then atom:info should be tossed.
We should either explicitly allow application/xml in section 2, or remove this element. I'm not sure which I prefer.
atom:info is useful during transformations. Tossing atom:info will result in interoperability problems. I don't see how application/xml relates, but if I were forced to make the choice, I would drop atom:info.
Robert Sayre
[1] http://www.w3.org/TR/REC-xml/#sec-guessing-with-ext-info
