I compiled a list of issues raised in the past. Although there
are seven issues in this list, I would like to concentrate on
the first issue for a while.
Issue 1: Proposals for additional parameters in the past
Namespace URI:
It specifies the URI of the top-level namespace of the XML document
Schema URI
It specifies the URI of the top-level schema of the XML document
DTD URI:
It specifies the URI of the DTD of the XML document
Class URI:
It specifies the class of the XML document which will be handled
by the same application programs (Note: RDF metadata are XML
documents without DTD's, but every RDF metadata can be handled
by the same program. XML documents with CSS stylesheets can be
displayed by WWW browsers, evenif they do not have DTDs.)
Conformance Profile URI:
It specifies an XHTML conformance profile.
Application URI:
It speficies the URI of application programs
Root element type:
This was suggested as an addition to the namespace/schema/DTD/class URI.
Issue 2: Type of XML mime entities
There are four types of XML MIME entities. In the XML terminology,
they are called "document entities", "external DTD subsets", "external
parsed entities", and "external parameter entities". The media types
text/xml and application/xml can be used for any of these four types.
Do we need some parameter to distinguish these four types? (Note that
a MIME entity can be an external parsed entity AND a document entity
at the same time. Some external DTD subsets can also be used as
external parameter entities.)
Issue 3: UTF-16
RFC 2376 should be revised when charsets for UTF-16 are registered.
Currently, there is an internet draft <draft-hoffman-utf16-02.txt>
for UTF-16 registration.
Issue 4: Characters .vs. bytes
An XML MIME entity is a sequence of characters as opposed to a
sequence of bytes. RFC 2376 is not really clear about this.
Issue 5: Packaging
There should be a mechanism for packaging an XML document together
with its stylesheet, catalog, and referenced resources (e.g., links,
external entities). One possibility is MHTML.
ftp://ftp.dsv.su.se/users/jpalme/draft-ietf-mhtml-info-11.txt
ftp://ftp.dsv.su.se/users/jpalme/draft-ietf-mhtml-rev-07.txt
Issue 6: Ambiguity of CCS conversion
If an XML document is encoded in some charset whose CCS is not
Unicode, XML processors will map the CCS to Unicode. For example, in
the case of Shift_JIS, we need a mapping from JIS X 0201 + JIS X0208
to Unicode. Unfortunately, there are more than one mapping in the
world. For example, the XML parser of IBM uses Javasoft mapping and
that of Javasoft uses Microsoft mapping. I heard that many other
charsets have such ambiguities.
If this is the case, it might make sense to introduce a parameter
"map" to precisely specify which mapping should be used.
Issue 7: The default of the charset parameter
Chris Lilley's recent proposal to revised RFC2376 is as below:
1) Require explicit charset for overriding the internal encoding
declaration, so if one really wants to re-label a document as US-ASCII
one actually has to send it out as text/xml; charset="US-ASCII"
2) Define the absence of an explicit charset encoding in the MIME
header not as "US-ASCII" but as "use encoding in XML instance" in
accordance with the XML 1.0 Recommendation.
Cheers,
Makoto
Fuji Xerox Information Systems
Tel: +81-44-812-7230 Fax: +81-44-812-7231
E-mail: murata(_at_)apsdc(_dot_)ksp(_dot_)fujixerox(_dot_)co(_dot_)jp