Subject: atom:type, xsl:output

From: Danny Ayers <[email-masked]>
Date: Mon, 23 May 2005 10:14:00 +0200

[forwarding for Jimmy, he's having mail problems]

From: Jimmy Cerra <[email-masked]>

I'm a little confused by the type attribute for atom:content and other
elements.  This the following correct?

* When @type="html" then the content of the element is a xsd:string
[1] of an HTML DIV element plus optional insignificant whitespace
around it.  Which version of HTML is defined?  How do you
differentiate between HTML 4.01, HTML 3.2, the upcoming HTML 5, or
"nonstandard" HTML (like with marquee elements)?

* When @type="xhtml" then the content of the element is a xhtml:div
XML fragment plus optional insignificant whitespace around it.  Again
which version of XHTML is defined?  How do you differentiate between
XHTML 1.0, 1.1, or 2.0? Since XHTML 2.0 may have a new namespace, so
will you allow that?  How does requiring XHTML:div impact which XHTML
modules are required (I have a guess)? And what about exotic versions
like "XHTML+MathML+SVG" or "XHTML 1.1 plus MathML 2.0"?  (Some blogs
actually use it "XHTML 1.1 plus MathML 2.0"!)

* When @type="text" then the content of the element is a xsd:string of
a text/plain document.

* When @type="mime/type" [2], ONLY for atom:content, then the content
(or src document) is that type of document.  Why not allow other
elements to use this? What about content that isn't compatible with
XML 1.0 (like XML 1.1, Turtle, RTF, PNG); should it be entity
encoded/put into cdata section like HTML?  What should one do when
encountering these situations?

Does that mean that if you use "application/xhtml+xml", you can do
(rest of feed omitted for brevity):

<atom:content type="application/xhtml+xml">
  <html xmlns="...">
    <head><title>...</title></head>
    <body> ... </body>
  </html>
</atom:content>

How do you specify xml-stylesheets processing instructions, doctype
and xml declarations, and other data about the content?  PIs may be a
non-issue if they are not read by the XML processor for the Atom feed;
although, that isn't guaranteed.

I think you should at least allow @type="xml", as others have
suggested for xml 1.0 content, along with adopting XSLT's output
attributes (perhaps not using @method or @media-type).  This would
ease the pain with XML, and all media/types for @type require the
content to be xsd:string valid (that is, entity encoded or using CDATA
sections).

Sorry for the boatload of questions.

--
Jimmy Cerra
http://pawsgroup.blogspot.com

[1] That is, a text node in the XML tree.

[2] A mime type, noting the exception in 4.1.3.1.

---

From: Graham <[email-masked]>
Date: Mon, 23 May 2005 10:43:53 +0100

> "nonstandard" HTML (like with marquee elements)?

I believe the answer would be "street HTML", not any specific version.

> elements to use this?

Because the other elements are for purely textual content.

> XML 1.1

Not supported.

> Turtle

Don't know.

> RTF

It is compatible, as a string, though certain obsolete characters are  
not.

> PNG

Should be base64 encoded.

> What should one do when encountering these situations?

See section 4.1.3.3  Processing Model

> (rest of feed omitted for brevity):

Yes. This is why we have a special XHTML mode for fragments.

Graham

---

From: Tim Bray <[email-masked]>
Date: Mon, 23 May 2005 08:50:15 -0700

> I believe the answer would be "street HTML", not any specific version.

Agreed.  What it says is "SHOULD be suitable for handling as HTML".   
I.e. can be passed to your local HTML rendering control, which is  
doubtless a forgiving tag-soup engine. -Tim

---

From: James Cerra <[email-masked]>
Date: Mon, 23 May 2005 21:06:20 -0700 (PDT)

Graham,

> I believe the answer would be "street HTML", not any

I don't like this, since the behavior of an unknown
version of HTML is obviously undefined.  You can't
expect any HTML processors (used to parse atom content
items) to follow the standards when the standard of
the instance being used is unknown!  There should be a
way to identify the version of html used so that the
behavior of the processor can be explicitly defined.

> Because the other elements are for purely textual

I understand.

> Not supported.

I'm confused.  There is nothing inherent in the spec
that prevents XML 1.1 or any future versions from
being supported.  And why introduce incompatibilities
in atom:content that also bork with arbitrary XML 1.0
documents too?  I assert this, because the spec says
in section 4.1.3.3, "Processing Model," that:

] 4.  If the value of "type" ends with "+xml" or
"/xml"
]     (case-insensitive), the content of atom:content
MAY include child
]     elements, and SHOULD be suitable for handling as
the indicated
]     media type.  If the "src" attribute is not
provided, this would
]     normally mean that the "atom:content" element
would contain a
]     single child element which would serve as the
root element of the
]     XML document of the indicated type.

First off: it is an error to lie about your
media-type, so I would change "SHOULD be suitable for
handling as the indicated media type" to "MUST be
suitable for handling as the indicated media type."

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.  SO the following could
legally be interpreted as either a text node or as
full-fledged xml:

] <atom:content type="application/xml">&lt;?xml
version="1.0?>
] &lt;tag /></atom:content>

There is no way to make even an educated guess in
advance without reading the text node with an xml
processor and seeing if it is well-formed.  This
really sucks for processing Atom with XSLT.

In any case, the above example could never be "the
root element of the XML document of the indicated
type" if written as xml instead of entity-escaped
either, since there is that pesky XML declaration. 
Yet it still conforms to what the mime type says it
is.  That's one reason why I think this is a bug in
the Atom spec.  It's also a reason why I wish
atom:content adopted xslt:output attributes for
specifying the doctype/xml declaration and version
info of the content.

Finally: In general there could also be processing
instructions that must be put as children of the
atom:content element, but how should they be
interpreted?  A non-atom aware processor will read
those processing instructions as belonging to the ATOM
DOCUMENT instead of the atom:content's XML CONTENT!

This is a horrible situation, especially when you want
the content of a blog to be an actual XML document
that uses XML declarations, DOCTYPE declarations, and
processing instructions.

There needs to be a way to specify these things
without using an external file referenced with a @src
attribute.

> Should be base64 encoded.

I understand, thanks.

> See section 4.1.3.3  Processing Model

Thanks for the pointer.  I can't believe I missed
that.

-- Jimmy Cerra

P.S.  Thanks you Danny Ayers, wherever you are!

__________________________________ 
Do you Yahoo!? 
Yahoo! Small Business - Try our new Resources site
http://smallbusiness.yahoo.com/resources/

---

From: "A. Pagaltzis" <[email-masked]>
Date: Tue, 24 May 2005 10:14:01 +0200

* James Cerra <[email-masked]> [2005-05-24 06:35]:
> > > XML 1.1
> > 
> > Not supported.
> 
> I'm confused.  There is nothing inherent in the spec that
> prevents XML 1.1 or any future versions from being supported.
> And why introduce incompatibilities in atom:content that also
> bork with arbitrary XML 1.0 documents too?  I assert this,
> because the spec says in section 4.1.3.3, "Processing Model,"
> that:

You can only embed XML 1.1 documents directly into another
document if that document is also XML 1.1. (Note that I am not
talking about transporting XML 1.1 documents as an opaque
serialized string.)

Embedding XML 1.1 documents inside an XML 1.0 document is not
possible, because
• XML 1.1 allows control characters to be included as entities
  which XML 1.0 forbids in any form,
• an XML 1.0 processor will not understand an embedded XML 1.1
  document,
• etc.

> ] 4.  If the value of "type" ends with "+xml" or "/xml"
> ]     (case-insensitive), the content of atom:content MAY
> ]     include child elements, and SHOULD be suitable for
> ]     handling as the indicated media type.  If the "src"
> ]     attribute is not provided, this would normally mean that
> ]     the "atom:content" element would contain a single child
> ]     element which would serve as the root element of the XML
> ]     document of the indicated type.
> 
> First off: it is an error to lie about your media-type, so I
> would change "SHOULD be suitable for handling as the indicated
> media type" to "MUST be suitable for handling as the indicated
> media type."

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.

> @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 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.

Regards,
-- 
Aristotle

---

From: Graham <[email-masked]>
Date: Tue, 24 May 2005 09:25:27 +0100

> suitable for handling as the indicated media type."

+1

> document), for example.

If I follow you right, you misunderstand. Atom documents are  
unambiguous. XML has to be inserted literally, with no entity  
escaping (except for entities that are part of text nodes) allowed.

> <atom:content type="application/xml">
> &lt;?xml version="1.0?>
> &lt;tag /></atom:content>

This is invalid, since it has no root element. It represents the  
standalone XML document:

<?xml version="1.0">
&lt;?xml version="1.0?>
&lt;tag />

This is correct:

<atom:content type="application/xml"><tag /></atom:content>

Graham

---

From: Tim Bray <[email-masked]>
Date: Tue, 24 May 2005 07:20:36 -0700

>> suitable for handling as the indicated media type."

I'm tempted to agree but can't, because the condition of "being  
suitable for handling as" is not deterministic and testable enough to  
merit a MUST. -Tim