Subject: suggestion: add new value to type attribute

From: Domel <[email-masked]>
Date: Mon, 02 May 2005 14:25:32 +0200

I think that you should add new value to type attribute (3.1.1) - xml
type="xml"
This value will allow embed not only text, HTML and XHTML but also 
others XML applications like SVG, SMIL etc.
Like in XSLT 2.0 draft in method attribute.

Dominik Tomaszuk

---

From: Eric Scheid <[email-masked]>
Date: Mon, 02 May 2005 22:43:39 +1000

> Like in XSLT 2.0 draft in method attribute.

the way it's done is that you put the mime-type of the xml into the type
attribute. That way you can not only have xml content, but you also clearly
communicate just what kind of xml it is.

e.

---

From: Graham <[email-masked]>
Date: Mon, 2 May 2005 14:03:00 +0100

> communicate just what kind of xml it is.

Actual 3.1.1 is the section on Text Constructs (atom:title,  
atom:summary, etc), which do not allow arbitrary XML, or MIME types  
in the type attribute.

In answer to the original suggestion, you may embed arbitrary XML in  
the atom:content element (as Eric described), but not in the title or  
summary, which are designed to be universally readable by any client,  
and thus have a limited feature set.

Graham

---

From: "Thomas Broyer" <[email-masked]>
Date: Mon, 2 May 2005 15:06:05 +0200 (CEST)

Eric Scheid wrote:
> attribute. That way you can not only have xml content, but you also
> clearly communicate just what kind of xml it is.

Note that this is only applicable to atom:content, not to Text Constructs,
as these are really meant to be textual content: title, subtitle, summary
and copyright.

As we're about it, it might be good to have some text about possible
future values and how Atom 1.0 compliant processors are supposed to handle
those values.
For example, assume Atom 2.0 adds the new value "docbook". How would Atom
1.0 processors treat a text construct with type="docbook"?

--
Thomas Broyer

---

From: Brett Lindsley <[email-masked]>
Date: Mon, 02 May 2005 09:25:25 -0500

One thought I had to make the TextConstruct and Content more similar
is to have a type attribute in the TextConstruct; however, the 
TextConstruct could
be limited to types of text/plain, text/html and text/xhtml. It would 
also eliminate the
need for special types of TEXT, HTML and XHTML.

Brett Lindsley, Motorola Labs

---

From: Domel <[email-masked]>
Date: Mon, 02 May 2005 16:42:24 +0200

Example of my type="xml"
Support SVG
<content type="xml" xml:lang="en">
<text xmlns="http://www.w3.org/2000/svg">
Hello, out there
</text>
</content>

Dominik Tomaszuk

---

From: Domel <[email-masked]>
Date: Mon, 02 May 2005 17:08:40 +0200

Brett Lindsley wrote:

> text/xhtml

application/xhtml+xml - RFC3236 ;-)

Dominik Tomaszuk

---

From: Brett Lindsley <[email-masked]>
Date: Mon, 02 May 2005 10:33:00 -0500

Nice catch. This does imply that processing embeded XML documents is
different than processing embedded text. Of course, we've been talking
about div, containers, namespaces, etc.

My thought on this was to treat an embedded XML document as a block
of escaped text and let a processor other than the Atom processor handle
it. Thus, text/plain, text/html and application/xhtml+xml ;-)  would all be
processed consistently (as a block of escaped text). Special case handling
(XML docs) would be done outside of the Atom parser without a need
to worry about the Atom context.

---

From: Anne van Kesteren <[email-masked]>
Date: Mon, 02 May 2005 17:39:49 +0200

> to worry about the Atom context.

XHTML is not escaped text and should not be treated as such imho.

-- 
  Anne van Kesteren
  <http://annevankesteren.nl/>

---

From: James Aylett <[email-masked]>
Date: Mon, 2 May 2005 16:47:31 +0100

> <text xmlns="http://www.w3.org/2000/svg">

<content type='image/svg+xml' xml:lang='en'>
<text xmlns="...">
Hello, out there
</text>
</content>

? (4.1.3.3.4.)

(Assuming <text> is an acceptable root element for SVG.)

James

-- 
/--------------------------------------------------------------------------\
  James Aylett                                                  xapian.org
  [email-masked]                               uncertaintydivision.org

---

From: Anne van Kesteren <[email-masked]>
Date: Mon, 02 May 2005 18:34:44 +0200

> (Assuming <text> is an acceptable root element for SVG.)

It isn't. application/xml is probably more appropriate.

---

From: Thomas Broyer <[email-masked]>
Date: Mon, 02 May 2005 20:38:04 +0200

> <text xmlns="http://www.w3.org/2000/svg">

SVG doesn't define embedding in other languages apart from providing a 
whole SVG document as defined by the SVG spec, e.g. in an "svg" element.
Actually, you must provide an SVG viewport, which is done with the "svg" 
element, and a viewport can be a self-contained SVG document.

<content type="image/svg+xml" xml:lang="en">
<svg xmlns="http://www.w3.org/2000/svg">
<text>Hello, out there</text>
</svg>
</content>

-- 
Thomas Broyer

---

From: James Aylett <[email-masked]>
Date: Mon, 2 May 2005 19:54:47 +0100

> It isn't. application/xml is probably more appropriate.

It would be, if SVG explained how to embed fragments in other XML
dialects. As I understand, it doesn't, in which case embedding the
entire document seems preferable. (Note that we've had to invent our
own way of embedding XHTML fragments in Atom - this isn't an uncommon
problem ...)

James

---

From: Thomas Broyer <[email-masked]>
Date: Mon, 02 May 2005 22:36:19 +0200

> own way of embedding XHTML fragments in Atom - this isn't an uncommon

So what is XHTMLMOD for?

We don't need XHTML metadata, as they are provided by the feed. We just 
need block or inline content models, which are generalized in the div 
and span containers, so we use their content model.

I don't think the WG have /invented/ an Atom way of embedding XHTML, 
they just *used* (maybe without knowing it) the XHTML modularization 
framework.

-- 
Thomas Broyer

---

From: "Thomas Broyer" <[email-masked]>
Date: Mon, 2 May 2005 15:06:05 +0200 (CEST)

--
Thomas Broyer