Subject: Re: atom:type, xsl:output

From: James Cerra <[email-masked]>
Date: Tue, 24 May 2005 20:43:14 -0700 (PDT)

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/

---

From: Henri Sivonen <[email-masked]>
Date: Wed, 25 May 2005 10:41:16 +0300

On May 25, 2005, at 06:43, James Cerra wrote:

> If the intended Atom content contains essential comments,

There should be no such thing as essential comments. The XML spec does 
not require XML processors to report comments to the app. Hence, 
comments are inappropriate for transferring essential data.

> processing instructions,

These could be supported in embedded content if the Atom spec said PIs 
in atom:content belong in content and should not be acted upon by the 
Atom processor.

> entities

Entities can be flattened.

> DOCTYPE declaration(s)

If DOCTYPE is essential for the receiving app, you've got bigger 
problems than Atom. Hardwiring IDness based on namespaces is more 
practical than relying on DTD-based data typing.

-- 
Henri Sivonen
[email-masked]
http://hsivonen.iki.fi/