W3C home > Mailing lists > Public > xsl-editors@w3.org > October to December 1999

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

From: Dan Connolly <connolly@w3.org>
Date: Wed, 24 Nov 1999 11:29:24 -0600
Message-ID: <383C2074.EEFC4B6E@w3.org>
To: MURATA Makoto <murata.makoto@fujixerox.co.jp>
CC: timbl@w3.org, simonstl@simonstl.com, ietf-xml-mime@imc.org, Tsmith@parc.xerox.com, xsl-editors@w3.org, masinter@parc.xerox.com
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@w3.org>
      Murata Makoto (Family Given) <murata@fxis.fujixerox.co.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/
Received on Wednesday, 24 November 1999 12:30:12 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Monday, 7 December 2009 10:59:49 GMT