[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Inconsistency between IETF and W3C: XML fragments and media types

www-html-editor: I suggest that the definition of the "type"
attribute on the HTML "link" element needs clarification.

MURATA Makoto wrote:
> We are writing this mail as co-authors of Internet Draft which is
> intended to replace RFC 2376.

Hmm... perhaps I've neglected some stuff that I should have read, but
I don't intend for any draft to replace RFC2376, and I'm
one of the contacts:

   "Person & email address for further information:

      Dan Connolly <connolly@xxxxxx>
      Murata Makoto (Family Given) <murata@xxxxxxxxxxxxxxxxxxxx>"
	-- http://www.ietf.org/rfc/rfc2376.txt

>  One of us (Murata) is also a co-author of
> RFC 2376 (XML Media Types).  We both participate in the IETF-XML-MIME
> mailing list hosted by IMC.
> There is an inconsistency between the IETF-XML-MIME ML and
> recently-published XSLT.

I don't believe so.

> People at the IETF-XML-MIME ML believe that XML fragments (which
> are referenced by fragment identifiers) do not have media types.


Unfortunately, there are two things that might be meant by 'XML
fragments'. One(1) is the subject of:

	XML Fragment Interchange 

This sort of XML Fragment is consistent with the existing
(RFC 2376) definiton of the text/xml MIME type: it's a
kind of XML entity, which is a sequence of characters that
has a standardized encoding as a sequence of bytes.

The other thing(2) that might be meant by 'XML fragments' is
for example, what http://example.net/foo.xml#fragID points
to. What that thing points to does *not* have a standardized
representation as a sequence of characters nor bytes, so
it can't have a MIME type.
It's a "node". c.f.

	XML Pointer Language (XPointer)

> However, the XSLT recommendation has an example stylesheet-linking PI,
> which specifies "text/xml" for an XML fragment.

I assume you're referring to

> However, the XSLT recommendation has an example stylesheet-linking PI,
> which specifies "text/xml" for an XML fragment.  Although James Clark
> agrees that fragments do not have media types, he was not able to
> remove "text/xml" from this example, since the "type" pseduo attribute
> is required by another recommendation "Associating Style Sheets with
> XML documents".

i.e. http://www.w3.org/1999/06/REC-xml-stylesheet-19990629/

My recollection is that type="..." is advisory: it helps user agents
optimize for the case that they don't know the relevant media type,
so they can skip fetching the thing. So it would be odd for it
to be mandatory. But sure enough! it is:

The following pseudo attributes are defined

alternate (yes|no) "no"

The semantics of the pseudo-attributes are exactly as with <LINK
REL="stylesheet"> in HTML 4.0

I wonder why it's mandatory.

Anyway.. regarding the semantics... the advisory stuff seems to have
lost somewhere:


type = content-type [CI] 
    When present, this attribute specifies the content type of a piece
    content, for example, the result of dereferencing a URI. Content
    are defined in [MIMETYPES]. 

The same text occurs at

Hmm... perhaps I can get this cleared up before HTML 4.01 becomes a

Anyway... the type="text/xml" in the XSLT spec example is saying:
"the stylesheet I'm pointing to is written in XML; if you don't
grok XML, don't bother fetching it." Given that interpretation,
I don't think it really matters that the pointer includes a fragid,
regardless of the sort of "type mismatch error" in givin a MIME
type for an XPointer node.

This is a case where it might be useful to have a specific MIME
type for XSL(T), so that you could say:

	"the stylesheet I'm pointing to is written in XSL; if you don't
	grok XSL, don't bother fetching it."

A namespace parameter on the text/xml media type would be another
way to convey that meaning.

>         (http://www.ietf.org/internet-drafts/draft-murata-xml-01.txt)

What's the difference between this an RFC 2376 anyway? Ah:

"   draft-murata-00: Application/xml-dtd, a naming convention (*/*-xml),
   and examples (application/mathml-xml, application/xsl-xml,
   application/rdf-xml, and image/svg-xml) are added."

I don't care for that idea.

Dan Connolly, W3C