Subject: HTML fragments in content constructs

From: David Powell <[email-masked]>
Date: Sun, 11 Jul 2004 19:52:19 +0100

It is a very common use-case that HTML content in an Atom entry will
be embedded amongst some other HTML and a bunch of other Atom entries.

So is there any restriction on the type of HTML tags that are allowed
in a content construct?

It is usual for entry content to be labeled as @type="text/html", but
really contain HTML fragments - not full HTML.

Should both of these be allowed:

a)

<atom:content mode="xml" type="application/xhtml+xml">
some <b>mixed</b> content
</atom:content>

b)

<atom:content mode="xml" type="application/xhtml+xml">
<html>
<head><title>Title</title></head>
<body><p>A complete file</p></body>
</html>
</atom:content>

Should we define what is expected in terms of the XHTML DTD [1] so
that people know how to frame the content - Eg: %Flow or %Block or
%Inline ?

Or is this out of our scope?

A few possible proposals:

  i) Just add a note to the spec to say that content constructs MAY
     contain fragments of the media type that they are declared to
     contain.

 ii) Say that HTML content SHOULD comply to a particular element set
     such as %Flow

iii) Add an attribute such as @framing="full|fragment" to the content
     construct.

or all of the above?

[1] http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd
 or http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd

-- 
Dave

---

From: Ken MacLeod <[email-masked]>
Date: 11 Jul 2004 14:14:12 -0500

David Powell <[email-masked]> writes:

> It is usual for entry content to be labeled as @type="text/html",
> but really contain HTML fragments - not full HTML.

Dave, take a look at PaceSimpleContentType, particularly the "Content
Profiles" section, and see if you agree with that.  That Pace was
written to address this issue, among a couple others.

  -- Ken

---

From: David Powell <[email-masked]>
Date: Mon, 12 Jul 2004 23:29:58 +0100

> written to address this issue, among a couple others.

Yes, I agree with those changes to the text content model. I don't see
any loss in scrapping @type, because using it to label HTML fragments
as text/html seems like an abuse of MIME anyway. I was also finding
@mode confusing when applied to non-HTML content and this model seems
clearer about that too.

Handling multimedia looks like a more contentious problem, there are a
lot of proposals and the differences look fairly subtle so I haven't
got a preference for that aspect of the proposal yet.

-- 
Dave