Subject: PaceMustBeWellFormed

From: Robert Sayre <[email-masked]>
Date: Thu, 03 Feb 2005 00:11:24 -0500

http://www.intertwingly.net/wiki/pie/PaceMustBeWellFormed

IMO, this Pace should be closed unless it is substantially rewritten 
before February 7th. The term "well-formed" has no place in this text, 
and should be replaced.

This is what well-formed means:

"[Definition: A textual object is a well-formed XML document if:]

    1. Taken as a whole, it matches the production labeled document.
    2. It meets all the well-formedness constraints given in this 
specification.
    3. Each of the parsed entities which is referenced directly or 
indirectly within the document is well-formed."

Stretching, extending, or profiling the XML specification and/or RFC3023 
  to lend weight to the text is totally inappropriate. All we can do is 
say "MUST" and define our own terms to the extent that we can.

Robert Sayre

---

From: Bill de hÓra <[email-masked]>
Date: Thu, 03 Feb 2005 09:55:16 +0000

Robert Sayre wrote:
> [...]

If,

  - 6.2 was dropped and probably
  - the first sentence of the Pace was dropped,
  - the rest of the 1st para was dropped down into 6.1
  - there was some weasel wording about RFC3023 compliance

how would you feel about the rest of it?

For example,

[[[
N Processing Atom markup

N.1 Determining the character encoding of an Atom feed

The concept of XML well-formedness relies on first determining the 
character encoding of the XML document. The rules for determining the 
character encoding of an Atom feed served over HTTP are no different to 
determining the character encoding of any XML document served over HTTP.
Those rules are defined by RFC 3023 and are considered normative by this 
specification. They are summarized here as there has been confusion over 
how RFC 3023 should be interpreted. In order to comply with RFC 3023:

  1. When serving an Atom feed, it is RECOMMENDED that publishers 
include the charset parameter along with the media type in the 
Content-type HTTP header.  If the charset parameter is present, clients 
MUST parse the Atom feed in that charset, ignoring any charset declared 
in the encoding attribute of the XML declaration.

  1. Publishers SHOULD serve Atom feeds with the media type 
"application/atom+xml" (registered in Section @@@ of this document).

  1. If a publisher wishes to serve an Atom feed over HTTP, but for some 
reason they are unable to use the "application/atom+xml" media type, the 
publisher SHOULD use "application/xml".

  1. Clients MUST determine the character encoding as per RFC 3023 or 
its successor.

  1. If a publisher is unable to serve their Atom feed with a 
Content-Type of "application/atom+xml" or "application/xml", they MAY 
use "text/xml".  Note: according to RFC 3023, XML documents served as 
"text/xml" with no charset parameter have a character encoding of 
"us-ascii".

  1. When serving an Atom feed as "text/xml", publishers MUST escape all 
non-US-ASCII characters as [http://www.w3.org/TR/REC-xml/#sec-references 
character references] to comply with RFC 3023.  For example, '&#xf8;' 
for the character 'ø'.

1. When retrieving an Atom feed served with a Content-type of "text/xml":

   1. clients MUST parse it with a "us-ascii" encoding in order .
   1. if such a feed contains non-US-ASCII characters, and clients MUST 
reject it as non-well-formed.

  1. Publishers MUST NOT serve Atom feeds with a media type other than 
the XML media types defined in RFC 3023 or its successor.  In particular 
Atom publishers are expected to note that "text/plain" is not an 
appropriate media type for an Atom feed.

1. When retrieving an Atom feed served with a non-XML media type,, 
clients MUST reject it as non-well-formed.
]]]

While I think we have to be realistic about people do with markup in the 
  wild, I find nothing above controversial or overconstraining in the 
above from a specification viewpoint. It's being worded in such a way 
that implementors can make a decision to comply with RFC 3023 or not. 
After a time, we'll be able to see whether or not RFC 3023 is actually 
useful, but right now, I don't see how we can punt on this matter.

cheers
Bill

---

From: Julian Reschke <[email-masked]>
Date: Thu, 03 Feb 2005 13:11:15 +0100

Bill de hÓra wrote:
> ...

I think the main issue here is first we say

1) ...SHOULD use application/atom+xml...

...then, if you don't want to...

2) ...SHOULD use application/xml...

...then finally...

3) otherwise MAY use text/xml.

That is a problem in itself. Either we mandate a specific content type 
or we don't (I think we should). If we mandate one, we should say that 
behaviour of documents served with a different type is simply undefined.

Note that most of the nasty RFC3023 problems only apply to text/*, in 
particular I don't see why we would want to RECOMMEND to use a charset 
parameter on application/* content types.

Best regards, Julian

-- 
<green/>bytes GmbH -- http://www.greenbytes.de -- tel:+492512807760