List of issues

[MURATA Makoto <[e-mail]>]

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: [phone]   Fax: [phone]
E-mail: [e-mail]