ietf-xml-mime
[Top] [All Lists]

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

1999-11-24 10:27:49
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(_at_)w3(_dot_)org>
      Murata Makoto (Family Given) 
<murata(_at_)fxis(_dot_)fujixerox(_dot_)co(_dot_)jp>"
        -- 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.

True.

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

        XML Fragment Interchange 
        http://www.w3.org/1999/06/WD-xml-fragment-19990630.html

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)
        http://www.w3.org/1999/07/WD-xptr-19990709


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

I assume you're referring to
http://www.w3.org/TR/1999/REC-xslt-19991116#section-Embedding-Stylesheets


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

href CDATA #REQUIRED
type CDATA #REQUIRED
title CDATA #IMPLIED
media CDATA #IMPLIED
charset CDATA #IMPLIED
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
been
lost somewhere:

========
http://www.w3.org/TR/1998/REC-html40-19980424/struct/links.html#adef-type-A

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

The same text occurs at
http://www.w3.org/TR/1999/PR-html40-19990824/struct/links.html#adef-type-A

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


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
http://www.w3.org/People/Connolly/