[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
RE: Fwd: Last Call: XML Media Types to Proposed Standard
We would prefer that application/xml and text/xml did not allow these kinds
of entities as well, but they are explicitly allowed in the predecessor
document, RFC 2376. It is generally considered bad form to invalidate
implementations that made a good faith effort to conform to the previous
form of the standard.
Thus, we used SHOULD NOT rather than MUST NOT. Of course, we expect the
availability of text/xml-external-parsed-entity and
application/xml-external-parsed-entity will do more than any SHOULD/MUST
distinction to cause implementers not to overload */xml.
Dan Kohn <mailto:dan@xxxxxxxxxxx>
From: Paul Grosso [mailto:pgrosso@xxxxxxxxxxxxx]
Sent: Wednesday, 2000-08-23 13:53
Subject: Re: Fwd: Last Call: XML Media Types to Proposed Standard
At 08:55 2000 08 17 +0900, MURATA Makoto wrote:
>Dan, Simon, and I have very slightly revised the I-D, on the basis of
>comments in this ML and comments we directly received. The new I-D is now
I note in section 3:
For backward compatibility, application/xml and text/xml MAY,
but SHOULD NOT, also be used for "external parsed entities",
"external DTD subsets", and "external parameter entities".
I don't see how external DTD subsets or external parameter
entities could be parsed or accessed as application/xml or
text/xml. I'm concerned that, by allowing such entities
to be given an application/xml or text/xml MIME type, we
will be saying, for example, that XPointer can now be used
to access them (since XPointer is the fragment identifier
syntax for resources of MIME type application/xml and text/xml)
and yet such resources don't have infosets and accessing them
using an XPointer is not defined.
I don't fully understand the backward compatibility argument,
but I'd prefer not to allow application/xml and text/xml to be
used on "external DTD subsets", and "external parameter entities".