Aristotle, > Embedding XML 1.1 documents inside an XML 1.0 document is not > possible, because...
I understand. Thanks. > An Atom processor does not know whether the embedded XML document > is a valid document of the given type. Only an attached processor > for the given document type will be able to decide. As such, the > validity of the Atom feed document is not affected by the media > type. It will, of course, cause interop problems if you lie about > the media type, hence SHOULD. That's convincing. > > Secondly, XML may be entity (or CDATA) encoded like > > @type="html" or plain xml like @type="xhtml". This is becuase > > of the "content of atom:content MAY include child elements" > > phrase. There is no guarantee if an entity escaped passage is > > xml or a text node example of an xml document (i.e. an example > > of an xml document), for example. > > No. Wrong. > > There is nothing saying that the content of atom:content MAY be a > text node. It MAY only be a child element. If it may be an element, then it may be something else too. By the definition in RFC 2119, this behavior (having one or more child elements according to 20050418 revision) is "truly optional." There's three other things it could be (ignoring comments and PIs): a text node, mixed content, no nothing at all. So it is still a valid Atom fragment. > If there is no child element, @src must be set, ie the XML > document constituting the content is external to the feed. > > I will say, though, the the spec could stand to be more explicit > in this instance. I agree with both your commentary on the spec and that your interpretation is mostly what Atom should support. Here's how I would write it: "4. If the value of "type" ends with "+xml" or "/xml" (case-insensitive), the content of atom:content MUST either consist of no children or one or more XML 1.0 elements, comments, processing instructions, an XML 1.0 text node, or mixed content [1]. Any comments, processing instructions, or entities found as children of atom:content MUST be interpreted as being associated with the Atom document itself. If the intended Atom content contains essential comments, processing instructions, entities, DOCTYPE declaration(s), or other properties that make it unable to be valid atom:content content, then it MAY be specified in an external file identified by a URI in the the "src" attribute, which MAY be interpreted by an Atom processor as being associated as the Atom content of the entry. The Atom content of the entry SHOULD be suitable for handling as the indicated media type." I defined a phrase, "Atom content," to represent the content of an entry, that is refernced by atom:content either through its src attribute or literally as its children elements and text nodes. Any comments or processing instructions should be explicitly associated with the Atom document's xml, rather than the "Atom content", so style information can be applied (for viewing the raw Atom XML) and the processing order of processing instructions and comments is well defined (to solve the problem of which ones to read and which ones to pass?) for examples. That paragraph is also very long-winded, but I think it is more precise than the existing paragraph. I don't know if it is deterministic, whatever that is, and I still think some of the attributes of xsl:output should be included as optional metadata about the atom:content child (doctype, xml declaration, etc.) if it is a complete document. -- Jimmy Cerra [1] <http://www.w3.org/TR/REC-xml/#sec-mixed-content> __________________________________ Do you Yahoo!? Yahoo! Small Business - Try our new Resources site http://smallbusiness.yahoo.com/resources/
