Subject: Re: Media typs and XPointer, XLink, XPath, and XSLT
From: Chris Lilley <[email-masked]>
To: John Cowan <[email-masked]>
Cc: [email-masked]
Date: Sat, 31 Jul 1999 23:34:43 +0200

John Cowan wrote:
> 
> Rick Jelliffe wrote:
> > I am confused about a related question: I have heard somewhere that
> > the XPointer group was going to make XPointers only valid for pointing
> > into XML documents.  So, for example, it would not be legitimate for
> > an XPointer to point into a WebCGM document or other structured data.  Is this true?
> 
> Since XPointers refer explicitly to element trees with attributes,
> an XPointer into CGM (which is a binary format) wouldn't make
> much sense. 

Right. And WebCGM defines its own fragment syntax (which was heavily
inspired by XLink, as it happens).

>  The real issue is whether XPointers can point into
> things like SMIL documents, which "just happen" to be encoded
> in XML.

When a new media type is registered, that registration gets to define
what sa fragment identifier means.

So, the language in the XPointer draft is clearly saying, for text/xml
and application/xml, this is the syntax. It doesn't say anything about
other media types, presumably because it can't speak for them.

Other media types can define their own fragment identifiers, which may
have very different requirements to Xlink or may have exactly the same
ones. So they might well say that they use XLink, too.

 Or they might say something like "we will allow only links to a given
ID but we will use the exact same syntax XPointer uses for that, for
compatibility". In other words, all valid fragment identifiers for thast
type would use XLink, but not all possible uses of XLink would be valid
for that media type.

--
Chris

From: "Larry Masinter" <[email-masked]>
To: "Simon St.Laurent" <[email-masked]>, <[email-masked]>
Subject: RE: Proposed Suffix for XML-based media types
Date: Fri, 23 Jul 1999 23:13:04 PDT
Importance: Normal
Sender: [email-masked]

> MIME Media Type Suffixes for XML-based Document Types

Even if this doesn't do *much* good, I see little harm in it.
The document would need to explain the choice of a suffix
rather than a prefix (text/xml.blah vs. text/blah-xml),
give a list of generic XML processing that might apply
(use of XPointer and XLink?), address the charset issue
(XML types either need to be UTF8 or else allow an explicit
charset parameter).

This would then be issued as a BCP, updating the registration
procedure BCP.

Larry

Date: Fri, 23 Jul 1999 11:27:13 -0700
From: Terry Allen <[email-masked]>
To: [email-masked], [email-masked]
Subject: Re: Introduction of media types for XML DTDs
Cc: [email-masked]
Sender: [email-masked]

Chris Lilley wrote:
| I would argue against text/xml-dtd only on the grounds of the general
| charset tangles with text/*, not on the basis of readability or
| otherwise. If I send a DTD to someone in email, its probably because I
| expect them to read it. If XML software fetches a DTD, its likely for
| machine processing and probably no-one reads it.

Except that browsers will be "XML software".  I'm convinced by Ned's
arguments against multiple types, but the solution to the problem
of display remains to be found.  In default of anything better, I
figure that if I intend the DTD for display, I'll just serve it
as text/plain.

Note that the issue will get worse with XML schemas, which are
instances and can be displayed as documents *after XML processing*.

regards, Terry

Terry Allen                             
Advanced Technology Group               
Commerce One, Inc.
Walnut Creek, Calif.
tallen[at]sonic.net

Date: Fri, 23 Jul 1999 19:52:58 +0200
From: Chris Lilley <[email-masked]>
To: Tim Bray <[email-masked]>
CC: [email-masked]
Subject: Re: Introduction of media types for XML DTDs
Sender: [email-masked]

Tim Bray wrote:
> 
> At 08:25 AM 7/17/99 PDT, Larry Masinter wrote:
> >I think there is no justification for "text/xml-dtd" in addition
> >to "application/xml-dtd", because there is no utility at all
> >for an unaware recipient to attempt to display a dtd to a
> >user as if it were text
> 
> Sounds plausible, but empirical evidence is against this position.
> Lots of people read DTDs all the time, and in fact since they are
> usually composed in monotype with all sorts of indentation and
> other pretty-printing apparatus, there is clearly an expectation
> that they be displayed. -Tim

Yes, each to their own; for example Tim (and I) would be happy reading a
DTD in plain text; Ned Freed would be happy reading RFC822 headers in
plain text, and so on and so forth.

And again, in practice, software does not use this "fallback" of
displaying text/unknown as text/plain so software would either know what
to do with a DTD or else it would offer to save it to disk or somesuch.

I would argue against text/xml-dtd only on the grounds of the general
charset tangles with text/*, not on the basis of readability or
otherwise. If I send a DTD to someone in email, its probably because I
expect them to read it. If XML software fetches a DTD, its likely for
machine processing and probably no-one reads it.

--
Chris

Date: Thu, 22 Jul 1999 00:17:23 -0800 (PST)
From: Ned Freed <[email-masked]>
Subject: Re: Introduction of media types for XML DTDs
To: John Cowan <[email-masked]>
Cc: "[email-masked]" <[email-masked]>
Sender: [email-masked]

> Ned Freed wrote:

> > [E]xperts don't want to send DTDs and similar
> > things to a dumb text viewer anyhow. They want their favorite programmable
> > editor, most likely one that is format-savvy for such things. This is certainly
> > how I have all the browsers I use configured.

> I guess I don't count as an expert, then.  My editor is 'ex';
> has been for many years, hopefully will be for many years to come.
> But why would I want to edit something I'm displaying through a
> browser?

Who said anything about editing? Editor != editing.

The point (which I thought was obvious) is that browser text displays are
fairly incompentent when it comes to displaying structured material. It just
isn't what they are designed for. An editor, especially one designed for
programming, typically does much better. Although I'll concede that in the case
of ex, that may not be the case...

				Ned

Date: Wed, 21 Jul 1999 15:43:34 -0800 (PST)
From: Ned Freed <[email-masked]>
Subject: Re: Introduction of media types for XML DTDs
To: Keith Moore <[email-masked]>
Cc: Ned Freed <[email-masked]>, MURATA Makoto <[email-masked]>, [email-masked]
Sender: [email-masked]

> > I completely agree -- and this is why I think the ability to fall back to text
> > for things like DTDs offers no real advantages for any significant group.

> I agree with this. however, another potential advantage comes to mind.

> If a body part is labelled "text/something" the MUA can convert the text
> to the local format when saving the file - e.g. newline delimited
> for UNIX, CR-delimited for Mac, fixed length 80 character ebcdic records
> for ancient IBM systems :).   The MUA can do this without having specific
> knowledge of the content-type.

> if the type is labelled "application/something" such a conversion
> would not be appropriate unless the MUA had specific knowledge
> of the content-type.

Actually, for some of these sorts of types, not converting can be a feature.
In some cases converting causes bad things to happen -- there can be
format and application dependencies on specific line terminators,
unfortunately.

				Ned

From: Keith Moore <[email-masked]>
To: Ned Freed <[email-masked]>
cc: MURATA Makoto <[email-masked]>, [email-masked]
Subject: Re: Introduction of media types for XML DTDs 
Date: Wed, 21 Jul 1999 13:50:38 -0400
Sender: [email-masked]

> I completely agree -- and this is why I think the ability to fall back to text
> for things like DTDs offers no real advantages for any significant group.

I agree with this. however, another potential advantage comes to mind.

If a body part is labelled "text/something" the MUA can convert the text
to the local format when saving the file - e.g. newline delimited
for UNIX, CR-delimited for Mac, fixed length 80 character ebcdic records 
for ancient IBM systems :).   The MUA can do this without having specific 
knowledge of the content-type.

if the type is labelled "application/something" such a conversion
would not be appropriate unless the MUA had specific knowledge 
of the content-type.

Keith

Date: Wed, 21 Jul 1999 10:41:34 -0400
From: John Cowan <[email-masked]>
Organization: Lojban Peripheral
To: "[email-masked]" <[email-masked]>
Subject: Re: Introduction of media types for XML DTDs
Sender: [email-masked]

Ned Freed wrote:

> [E]xperts don't want to send DTDs and similar
> things to a dumb text viewer anyhow. They want their favorite programmable
> editor, most likely one that is format-savvy for such things. This is certainly
> how I have all the browsers I use configured.

I guess I don't count as an expert, then.  My editor is 'ex';
has been for many years, hopefully will be for many years to come.
But why would I want to edit something I'm displaying through a
browser?

-- 
	John Cowan	http://www.ccil.org/~cowan	[email-masked]
Schlingt dreifach einen Kreis um dies! / Schliesst euer Aug vor heiliger Schau,
Denn er genoss vom Honig-Tau / Und trank die Milch vom Paradies.
			-- Coleridge / Politzer

Date: Wed, 21 Jul 1999 07:30:44 -0800 (PST)
From: Ned Freed <[email-masked]>
Subject: Re: Introduction of media types for XML DTDs
To: MURATA Makoto <[email-masked]>
Cc: [email-masked]
Sender: [email-masked]

> > On the contrary; it is a weakness of current browsers that there
> > is no way to tell them "Display such-and-such a media type as
> > text/plain in the main window."

> At best, this is a criticizm on current browsers.  Moreover, even
> current browsers make me happy, since I can tell them "Display
> such-and-such a media type as with my faviroite text viewer
> (which is not IE 5.0)"

I completely agree -- and this is why I think the ability to fall back to text
for things like DTDs offers no real advantages for any significant group.
Normal users will be confused (and we have ample evidence of this in terms
of complaints to support lines), and experts don't want to send DTDs and similar
things to a dumb text viewer anyhow. They want their favorite programmable
editor, most likely one that is format-savvy for such things. This is certainly
how I have all the browsers I use configured. 

Also keep in mind that in some contexts override of plain text viewing with
your own application can't be done. (Again, this is a limitation of current
applications and hence not directly relevant, but it is a much more real
issue than the similar one raised above.)

				Ned

From: MURATA Makoto <[email-masked]>
Date: Wed, 21 Jul 1999 13:40:27 +0900
To: [email-masked]
Subject: Re: Introduction of media types for XML DTDs
Sender: [email-masked]

Thank you very much, Ned. I have come to believe that we only need 
application/xml-dtd.  

Terry Allen wrote:
> For the case when it is desired to display the DTD, Ned stated that 
> text/xml was the wrong way to go, and suggested that something else,
> such as content-disposition, could be used to cue the user agent to
> display as text.  Does any such method work today?

Yes, you can tell browsers to invoke Notepad.

John Cowan wrote:
> 
> On the contrary; it is a weakness of current browsers that there
> is no way to tell them "Display such-and-such a media type as
> text/plain in the main window."

At best, this is a criticizm on current browsers.  Moreover, even 
current browsers make me happy, since I can tell them "Display 
such-and-such a media type as with my faviroite text viewer 
(which is not IE 5.0)"

Miles Sabin wrote:
>  Most users won't ever do that,
> but that seems fairly slender grounds for throwing away
> at MIME level the knowledge that DTD text is text. 

Browsers only have to invoke text editors when they encounter application/xml-dtd.

Makoto
 
Fuji Xerox Information Systems
 
Tel: +81-44-812-7230   Fax: +81-44-812-7231
E-mail: [email-masked]

From: "Larry Masinter" <[email-masked]>
To: "MURATA Makoto" <[email-masked]>, <[email-masked]>
Subject: Defining 'fragment identifier' behavior because of XML-based MIME type
Date: Tue, 20 Jul 1999 11:40:04 PDT
Importance: Normal
Sender: [email-masked]

> I have a question.  Why do we have to use media types here?  If an XML 
> document contains a link which takes advantage of XPointer, we just know 
> that the URI references to an XML document and thus do not have to be 
> notified by XML media types.  

This is dangerous; you would be limiting the applicability of
XPointer to only work with XML. What if someone were to invent,
oh, a "binary XML". (There are several efforts to do so.) XPointer
references might just as well apply to binary XML.

Would it be possible to extend XPointer to work with Zip files
which contained XML files, so that you could point into an XML
document that was stored inside a ZIP file?

Then you wouldn't know that "the URI references to an XML document".

Restricting XPointer only to work with XML would be limiting it
unnecessarily.

The ability to do generic XML linking into internal body parts
of XML-encoded data might be a reason for calling out XML-specific
media types, especially if XML documents are "compound" and the
media type used just indicates the "top level". 

So far, this is the first example that resonates with me,
although it might be that "application/xml" is good enough
for all of these examples, with a separate content-disposition
or content-features for calling out either the intention
for how the sender might want the information processed by
the recipient, or some indication as to the namespaces or
other content features of the XML body.

Larry

Date: Tue, 20 Jul 1999 13:27:05 -0400
To: [email-masked]
From: Paul Grosso <[email-masked]>
Subject: Re: Soundbite: Proposed Suffix for XML-based media types
Sender: [email-masked]

At 00:49 1999 07 21 +0900, Murata Makoto wrote:
>There is certainly some value, since specialized media types can enjoy 
>XML-generic support.  IE 5.0 does "generic processing of XML" by displaying 
>the element hierarchy.  If we interpret fragment identifiers of XML-based 
>media types as XPointer, that will be another example of "generic processing 
>of XML". (Does the same thing apply to XML fragment interchange?  > PaulG)  

I believe so in the sense that XML Fragment interchange can be used with
any XML resource with no knowledge about the resource beyond generic XML
information.

Date: Tue, 20 Jul 1999 09:52:23 -0700
To: [email-masked]
From: Tim Bray <[email-masked]>
Subject: Re: Soundbite: Proposed Suffix for XML-based media types 
Sender: [email-masked]

At 06:54 AM 7/20/99 -0400, Keith Moore wrote:
>I think it's a silly idea.  There's very little value in generic processing
>of XML; there's even less value in having an extra level of delegation.

How can this assertion be anything but vacuous?  XML is a new thing in the 
world and we're just learning how to deal with it.  At this moment, basically
*all* the tools available to deal with XML resources are totally generic.  I 
do *not* extrapolate from this to assert that generic-XML processing is the 
right way to go in general; that would be silly.  It is equally silly to 
assert that generic processing has no value.  Since we manifestly, obviously, 
inarguably, JUST DON'T KNOW right now, it seems to me that whatever we do with 
media-types, we should be very very careful to avoid closing off 
maybe-interesting paths.  -Tim

From: Murata Makoto <[email-masked]>
Date: Wed, 21 Jul 1999 00:49:19 +0900
To: [email-masked]
Subject: Re: Soundbite: Proposed Suffix for XML-based media types
Sender: [email-masked]

In message "Re: Soundbite: Proposed Suffix for XML-based media types",
Keith Moore wrote...
 >> All MIME media types for XML-based documents will get the suffix '-xml'.
 >
 >I think it's a silly idea.  There's very little value in generic processing
 >of XML; there's even less value in having an extra level of delegation.

There is certainly some value, since specialized media types can enjoy 
XML-generic support.  IE 5.0 does "generic processing of XML" by displaying 
the element hierarchy.  If we interpret fragment identifiers of XML-based 
media types as XPointer, that will be another example of "generic processing 
of XML". (Does the same thing apply to XML fragment interchange?  > PaulG)  
After all, interpretation of fragment identifiers has not been well addressed 
by MIME yet.

In message "Re: Proposed Suffix for XML-based media types",
Keith Moore wrote...

 >nobody has demonstrated a need for an extra level of type classification. 
 >nobody has demonstrated a need for an extra level of fallback behavior.  
 >if anything, experience with the existing two-level type system 
 >indicates that fallback behaviors are of dubious value.

There is no consensus, as I see it.  Some people believe that the existing 
two-level type system is fine, while others are convinced that it is not 
enough.  Each camp has failed to persuade the other.  Simon's proposal is 
intended as a compropmise.  If people live with it, I think that it is 
a reasonable solution.

Cheers,

Makoto
 
Internet: [email-masked]
Nifty: VEQ00625

From: Keith Moore <[email-masked]>
To: Steven Pemberton <[email-masked]>
cc: Keith Moore <[email-masked]>, "Simon St.Laurent" <[email-masked]>, [email-masked]
Subject: Re: Proposed Suffix for XML-based media types 
Date: Tue, 20 Jul 1999 11:29:03 -0400
Sender: [email-masked]

> I thought this whole discussion was based on a perceived need for
> extra levels of type classification and fallback.

perceived != demonstrated.  I certainly haven't seen a convincing argument.

From: Steven Pemberton <[email-masked]>
Date: Tue, 20 Jul 1999 16:47:27 +0200 (MET DST)
To: Keith Moore <[email-masked]>
Cc: "Simon St.Laurent" <[email-masked]>, [email-masked]
Subject: Re: Proposed Suffix for XML-based media types 
Sender: [email-masked]

 > a two-level type system was an explicit design decision
 > of the 822ext working group.  this decision was made for good and valid 
 > reasons, and nothing which has happened since has demonstrated that 
 > such a decision was shortsighted.  in particular:
 > 
 > nobody has demonstrated a need for an extra level of type classification. 
 > nobody has demonstrated a need for an extra level of fallback behavior.  

I thought this whole discussion was based on a perceived need for
extra levels of type classification and fallback.

Steven Pemberton

Date: Tue, 20 Jul 1999 10:30:21 -0400
To: [email-masked]
From: "Simon St.Laurent" <[email-masked]>
Subject: Re: Proposed Suffix for XML-based media types 
Sender: [email-masked]

At 09:28 AM 7/20/99 -0400, Keith Moore wrote:
>[Steven Pemberton wrote:]
>> Now when we need an extra layer of fallback, it is obvious how to do
>> it:
>> 
>>         text/xml/xhtml
>
>sorry, it's not going to happen.  the MIME content-type syntax is 
>well-established; changing it would break a huge amount of deployed software.

On this count, I've surrendered long ago and agree with Keith, though
fortunately that's not what I'm proposing here.

>furthermore a two-level type system was an explicit design decision
>of the 822ext working group.  this decision was made for good and valid 
>reasons, and nothing which has happened since has demonstrated that 
>such a decision was shortsighted.  in particular:

In this case, I think XML - and other continuing developments around the
concept of generic formats - have made a significant case for the creation
of formats that can be used with multiple vocabularies.  At this point,
especially with the rapid growth of XML and supporting generic XML
standards (XPointer, XLink, XSL, CSS, and others), I have no qualms about
saying that generic XML processing is both useful and important to
meaningful information exchange.
 
>nobody has demonstrated a need for an extra level of type classification. 
>nobody has demonstrated a need for an extra level of fallback behavior.  
>if anything, experience with the existing two-level type system 
>indicates that fallback behaviors are of dubious value.

I would hope you explore sections 2 and 4 of the full proposal.  XML was
designed explicitly to be a solid foundation for many document types, in
effect a 'fallback' of very sound value.  

At the time RFC 822 was written, I think they pretty much did the right
thing, and I'm willing to live as close to their rules as possible (which
is why the proposal uses a suffix, not an extra level with /).  However, I
think we should seriously consider the fact that XML has changed the rules
significantly, in a way which appears to be gathering widespread support
and generating new media types at a feverish pace.

Simon St.Laurent
XML: A Primer / Building XML Applications
Inside XML DTDs: Scientific and Technical
Sharing Bandwidth / Cookies
http://www.simonstl.com

From: Keith Moore <[email-masked]>
To: Steven Pemberton <[email-masked]>
cc: "Simon St.Laurent" <[email-masked]>, [email-masked]
Subject: Re: Proposed Suffix for XML-based media types 
Date: Tue, 20 Jul 1999 09:28:12 -0400
Sender: [email-masked]

> I very much like Dan Connolly's suggestion of a time back:
> 
>         Regard a media type as relative URL rooted at some agreed
>         place, probably iana.org so that the media type text/xml then
>         represents the URL
> 
>                 http://iana.org/text/xml
> 
> (or similar).
> 
> Now when we need an extra layer of fallback, it is obvious how to do
> it:
> 
>         text/xml/xhtml

sorry, it's not going to happen.  the MIME content-type syntax is 
well-established; changing it would break a huge amount of deployed software.
furthermore a two-level type system was an explicit design decision
of the 822ext working group.  this decision was made for good and valid 
reasons, and nothing which has happened since has demonstrated that 
such a decision was shortsighted.  in particular:

nobody has demonstrated a need for an extra level of type classification. 
nobody has demonstrated a need for an extra level of fallback behavior.  
if anything, experience with the existing two-level type system 
indicates that fallback behaviors are of dubious value.

Keith

From: Steven Pemberton <[email-masked]>
Date: Tue, 20 Jul 1999 13:55:32 +0200 (MET DST)
To: "Simon St.Laurent" <[email-masked]>
Cc: [email-masked]
Subject: Re: Proposed Suffix for XML-based media types
Sender: [email-masked]

Simon St.Laurent writes:
 > [This is a more formal expansion of my earlier 'modest proposal'
 > (http://www.imc.org/ietf-xml-mime/mail-archive/msg00149.html), which seemed
 > to generate some interest.  This is an extremely rough draft and has no
 > official status of any kind.  All comments, revisions, improved
 > descriptions, better examples, outrage, etc. are welcome.]

My basic problem with this proposal is that it says

	* We need more than one level of fall back
	* To fix this we are going to start interpreting the string
	  after the slash to add another layer of structure

i.e. media types are no longer supporting our needs fully.

In that case I would say: fix the problem, don't try to bandage it
over.

I very much like Dan Connolly's suggestion of a time back:

	Regard a media type as relative URL rooted at some agreed
	place, probably iana.org so that the media type text/xml then
	represents the URL

		http://iana.org/text/xml

(or similar).

Now when we need an extra layer of fallback, it is obvious how to do
it:

	text/xml/xhtml

for instance.

Best wishes,

Steven Pemberton
CWI, Amsterdam

From: Keith Moore <[email-masked]>
To: "Simon St.Laurent" <[email-masked]>
cc: [email-masked]
Subject: Re: Soundbite: Proposed Suffix for XML-based media types 
Date: Tue, 20 Jul 1999 06:54:27 -0400
Sender: [email-masked]

> All MIME media types for XML-based documents will get the suffix '-xml'.

I think it's a silly idea.  There's very little value in generic processing
of XML; there's even less value in having an extra level of delegation.

Keith

Date: Mon, 19 Jul 1999 14:52:37 -0800 (PST)
From: Ned Freed <[email-masked]>
Subject: Re: Introduction of media types for XML DTDs
To: MURATA Makoto <[email-masked]>
Cc: [email-masked]
Sender: [email-masked]

> Ned, since you co-authored MIME RFCs, could you please give us an explicit
> criteria of text subtypes?

The problem is that the criteria have changed over time as our understanding of
actual use of markup formats has changed. When MIME was designed we were told
that various formats, notably text/richtext, then text/enriched, and even
text/html, would be capable of being used in such a way that the output would
be readable as-is -- far from beautiful, to be sure, but readable, and that
applications were prepared to do this. Under this theory any material that in
theory could be read a plain text should be registered under text.

But this hasn't happened. In practice the text/richtext, text/enriched, and
text/html applications actually produce is typically an unreadable mess -- in
some cases even by someone fully familiar with the format. (Note that there are
some well behaved applications out there that do generate legible
text/enriched, but they are dwarfed in number by the poorly behaved ones.)

And given these registrations, the practice of putting things under two trees
has carried over to many other types because a feeling has arisen that a
"correctly" registered SGML-derived type needs both a text and application
registration. So we have a bunch of registrations I for one regard as anywhere
from useless to dangerous. (I try to push back on these as media types
reviewer, especially the practice of putting the text-encoding variant under
text and the WAP WBXML binary variant under application,  but I'm only
successful in some cases, not all.)

> You appear to claim that text subtypes
> have to be readable by casual users.

This was always the underlying intent. But what has happened is that many
things have been registered given the promise of readability, and this
has then cascaded into ever sillier registrations.

> However, text/css, text/rfc822-headers,
> text/vnd.in3d.3dml, text/rtf are already registered.

With the sole exception of text/rfc822-headers, I view all of these
as mistakes.

> I do not think
> that they are quite readable by casual users.  On the other hand, Postscript
> programs are application/postscript rather than text/postscript.  Is text/css
> a mistake?

Text/css is one of the more egregious ones, I think.

In the case of PostScript some people actually argued that readable PostScript
was a possibility. But nobody seriously thought PostScript output drivers would
ever spit out such a thing, so it never got registered under text.

> Should XSL become application/xsl-xml rather than text/xsl-xml?

I certainly think it should.

				Ned

Date: Mon, 19 Jul 1999 18:14:00 -0400
To: [email-masked]
From: "Simon St.Laurent" <[email-masked]>
Subject: Soundbite: Proposed Suffix for XML-based media types
Sender: [email-masked]

I've been told my last posting was too long, so here's the short version.

All MIME media types for XML-based documents will get the suffix '-xml'.

The registration process will follow normal IETF procedures per RFC 2048.

Advantages: Applications that can process XML generically will be able to
request content types of */*xml and get useful results for further
processing.  Tools designed to work with XML in general (XPointer, XLink,
style sheets) will be easy to use with any registered MIME type that uses XML.

Disadvantages: Er... four extra bytes in the content-type header?

Simon St.Laurent
XML: A Primer / Building XML Applications
Inside XML DTDs: Scientific and Technical
Sharing Bandwidth / Cookies
http://www.simonstl.com

Date: Mon, 19 Jul 1999 14:13:45 -0400
From: John Cowan <[email-masked]>
Organization: Lojban Peripheral
To: [email-masked]
Subject: Re: Introduction of media types for XML DTDs
Sender: [email-masked]

Terry Allen wrote:

> | The average user probably will never fetch a document of type
> | */xml-dtd.
> 
> I hope that's false.  I hope the average user's user agent will be
> fetching DTDs all the time, for use with documents marked up in
> accordance with them.  And I hope their browsers don't display
> the DTDs to them.

Indeed. I was referring to an explicit fetch.  "Users don't fetch
DTDs (or stylesheets), their browsers fetch DTDs (or stylesheets)."

-- 
	John Cowan	http://www.ccil.org/~cowan	[email-masked]
Schlingt dreifach einen Kreis um dies! / Schliesst euer Aug vor heiliger Schau,
Denn er genoss vom Honig-Tau / Und trank die Milch vom Paradies.
			-- Coleridge / Politzer

Date: Mon, 19 Jul 1999 13:00:00 -0400
To: [email-masked]
From: "Simon St.Laurent" <[email-masked]>
Subject: Proposed Suffix for XML-based media types
Sender: [email-masked]

[This is a more formal expansion of my earlier 'modest proposal'
(http://www.imc.org/ietf-xml-mime/mail-archive/msg00149.html), which seemed
to generate some interest.  This is an extremely rough draft and has no
official status of any kind.  All comments, revisions, improved
descriptions, better examples, outrage, etc. are welcome.]

-------------------------------------

MIME Media Type Suffixes for XML-based Document Types

1. ABSTRACT

This document describes the use of a naming convention (a suffix of '-xml')
for identifying XML-based MIME media types, whatever their particular
contents may represent.  This allows the use of generic XML processors and
technologies on a wide variety of different XML document types at a minimum
cost, using existing frameworks for media type registration.

2. INTRODUCTION

Extensible Markup Language [XML] provides a generic syntax for structured
text documents which can be used to define a wide variety of specific
document types.  RFC 2376 [XML-Media] described two MIME Media Types
(text/xml and application/xml) which can be used with 'generic' XML.  As
XML development continues to develop, new XML document types are appearing
rapidly. Many of these XML document types would benefit from the
identification possibilities of a more specific MIME media type than
text/xml or application/xml can provide, and it is likely that many new
media types for XML-based document types will be registered in the near and
ongoing future.

While the benefits of specific MIME types for particular types of XML
documents are significant, all XML documents share common structures and
syntax that make possible common processing.   XML's supporting standards,
notably XPointer, are designed to work with any XML document, whatever
vocabulary it uses. Any XML editor should be able to read, modify, and save
any XML document.  Search engines and agents should be able to read XML
documents and extract the content and names of elements and attributes even
if they are ignorant of the particular vocabulary used for elements and
attributes.  XML-oriented storage systems, which keep XML documents
internally in a parsed form, should similarly be able to process, store,
and recreate any XML document, whatever the MIME media type of that XML
document may be.  

Combining the benefits of more specific typing of documents and generic XML
processing requires generic XML applications to adopt one or more of three
approaches:

1) Use a trial-and-error approach that involves downloading documents and
checking their contents to determine whether or not they are XML documents.

2) Keep track of all MIME media types, and know which types represent XML
documents and which do not.

3) Recognize a convention that allows MIME media types to describe specific
types of documents created with XML while still identifying that the base
syntax is XML.

The first approach wastes network and processing resources every time a new
media type is encountered.  The second is more efficient, but requires
manual updating (at present) and may involve fallback to approach number 1.
 The third approach gives applications a consistent labelling standard that
allows for the automatic addition of new media types to generic
applications without disruption or wasted connections.

This proposal does not address more complex content negotiation issues that
may be necessary for applications to determine whether the recipient
understands the particular vocabulary sets used within given XML document
types.  The media type described here could be used by applications to
prepare for such negotiation, but the media type only provides a monolithic
description of a document type.

3. NEW XML MEDIA TYPES

When a new media type is introduced for an XML-based format, the name of
the media type should end with "-xml".  This will allow applications that
can process XML generically to detect that the file is supposed to be an
XML document as described in [XML] and process it accordingly.  The
registration process for these media types is described in RFC 2048
[MIME-Registration].  The registrar for the IETF tree will enforce this
rule for all XML-based media types created in the IETF tree.  Registrars
for other trees should follow this convention in order to ensure maximum
interoperability of their XML-based documents.

The optional charset parameter may be used with media types following these
conventions as described in RFC 2376 or its successors.

4. PROCESSING XML MEDIA TYPES

Two general classes of applications will operate on XML documents.  The
first class operates on specific types of documents indicated by the
complete MIME media type. For example, a display applet that renders
Scalable Vector Graphics [SVG] will only be interested in XML documents of
type 'image/svg-xml', not documents of type 'image/gif' or
'application/xpdl-xml'.  

Other ('generic') applications may work on any XML documents they
encounter, processing any media type that matches the type '*/*xml'. This
will match text/xml and application/xml as well as more specific media
types ending in -xml, allowing the application to request and process XML
documents represented by any XML-specific media type.  While these
applications may not understand the semantic meaning of particular
vocabularies, they will be able to process the information stored in the
document, determine its structure, and present it to a human or machine
consumer in some form.

5. EXAMPLES

XML-based media types may represent information in any of the discrete
top-level MIME types described in RFC 2046 [MIME-Types]. The examples below
present possible names for XML-based media types using the notation
described about.

5.1 text types

If a standard XML-based format for memorandums emerged, an appropriate
media type might be:

text/memo-xml

5.2 image types

If the World Wide Web Consortium (W3C) were to register a media type for
its XML-based Scalable Vector Graphics [SVG], an appropriate media type
might be:

image/svg-xml

5.3 audio types

While multimedia applications are not considered a likely area for XML
development, XML could be used to provide a metadata wrapper around other
audio formats or could store some types of audio information directly.  An
XML-based format for music called MusicML could be registered as:

audio/musicml-xml

5.4 video types

While multimedia applications are not considered a likely area for XML
development, XML could be used to provide a metadata wrapper around other
video formats or could store some types of video information directly.  An
XML-based format for video called VideoML could be registered as:

video/videoml-xml

5.5 application types

If XML Processing Description Language (XPDL) were to be registered as a
media type, it could be registered as:

application/xpdl-xml

5.6 model types

XML is also suitable for a wide variety of modeling applications.  If, for
instance, a Structured Programming Modeling Markup Language were to appear,
it could be registered as:

model/spmml-xml

6. REFERENCES

XML	Bray, Tim, Paoli, Jean, and Sperberg-McQueen, C.M.  Extensible Markup
Language (XML) 1.0. (W3C Recommendation 10-February-1998)
http://www.w3.org/TR/REC-xml

XML-Media	Whitehead, E. and Murata, M.  XML Media Types. (RFC 2376, July
1998) http://www.rfc-editor.org/rfc/rfc2376.txt

MIME-Registration	Freed, N., Kleinsin, J., and Postel, J.  Multipurpose
Internet Mail Extensions (MIME) Part Four: Registration Procedures. (RFC
2048, November 1996.)  http://www.rfc-editor.org/rfc/rfc2048.txt

MIME-Types	Freed, N., and Borenstein, N.  Multipurpose Internet Mail
Extensions (MIME) Part Two: Media Types. (RFC 2046, November 1996.)
http://www.rfc-editor.org/rfc/rfc2046.txt

SVG	Ferraiolo, Jon, et al.  Scalable Vector Graphics. (W3C Working Draft,
06 July 1999.)  http://www.w3.org/TR/SVG/

Simon St.Laurent
XML: A Primer / Building XML Applications
Inside XML DTDs: Scientific and Technical
Sharing Bandwidth / Cookies
http://www.simonstl.com

From: Miles Sabin <[email-masked]>
To: "[email-masked]'" <[email-masked]>
Subject: RE: Introduction of media types for XML DTDs
Date: Mon, 19 Jul 1999 17:50:33 +0100
Sender: [email-masked]

Terry Allen wrote,
> John Cowan wrote,
> > The average user probably will never fetch a 
> > document of type */xml-dtd.
>
> I hope that's false.  I hope the average user's user 
> agent will be fetching DTDs all the time, for use with 
> documents marked up in accordance with them.

<pedantic>
A users user-agent fetching a DTD is quite different
from a user fetching a DTD directly (eg. by typing it's
URL into their UAs address line).
</pedantic>

Pedantry aside, this is an important distinction (one
I presume John had in mind when he wrote what he wrote).
If I explicitly fetch a textual DTD resource I'd
expect it to be rendered textually without having to
take any special action. Most users won't ever do that,
but that seems fairly slender grounds for throwing away
at MIME level the knowledge that DTD text is text. 

Cheers,

Miles

-- 
Miles Sabin                          Cromwell Media
Internet Systems Architect           5/6 Glenthorne Mews
+44 (0)181 410 2230                  London, W6 0LJ
[email-masked]           England

Date: Mon, 19 Jul 1999 09:06:05 -0700
From: Terry Allen <[email-masked]>
To: [email-masked], [email-masked]
Subject: Re: Introduction of media types for XML DTDs
Sender: [email-masked]

John Cowan re Ned Freed: 
| 
| > I agree. And I'm sorry, but the argument that "people expect DTDs to be
| > displayed as text" just doesn't wash -- technical experts (who are capable
| > of configuring their agents to do anything they want)'
| 
| On the contrary; it is a weakness of current browsers that there
| is no way to tell them "Display such-and-such a media type as
| text/plain in the main window."
| 
| > the average user doesn't know diddly about XML or DTD and doesn't want a
| > bunch of incomprehensible stuff displayed on his or her screen.
| 
| The average user probably will never fetch a document of type
| */xml-dtd.

I hope that's false.  I hope the average user's user agent will be
fetching DTDs all the time, for use with documents marked up in
accordance with them.  And I hope their browsers don't display
the DTDs to them.

For the case when it is desired to display the DTD, Ned stated that 
text/xml was the wrong way to go, and suggested that something else,
such as content-disposition, could be used to cue the user agent to
display as text.  Does any such method work today?

regards, Terry

Terry Allen                             
Advanced Technology Group               
Commerce One, Inc.
Walnut Creek, Calif.
tallen[at]sonic.net

Date: Mon, 19 Jul 1999 11:32:09 -0400
From: John Cowan <[email-masked]>
Organization: Lojban Peripheral
To: [email-masked]
Subject: Re: Introduction of media types for XML DTDs
Sender: [email-masked]

Ned Freed wrote:

> I agree. And I'm sorry, but the argument that "people expect DTDs to be
> displayed as text" just doesn't wash -- technical experts (who are capable
> of configuring their agents to do anything they want)'

On the contrary; it is a weakness of current browsers that there
is no way to tell them "Display such-and-such a media type as
text/plain in the main window."

> the average user doesn't know diddly about XML or DTD and doesn't want a
> bunch of incomprehensible stuff displayed on his or her screen.

The average user probably will never fetch a document of type
*/xml-dtd.

-- 
	John Cowan	http://www.ccil.org/~cowan	[email-masked]
Schlingt dreifach einen Kreis um dies! / Schliesst euer Aug vor heiliger Schau,
Denn er genoss vom Honig-Tau / Und trank die Milch vom Paradies.
			-- Coleridge / Politzer

From: MURATA Makoto <[email-masked]>
Date: Mon, 19 Jul 1999 11:33:38 +0900
To: [email-masked]
Subject: Re: Introduction of media types for XML DTDs
Sender: [email-masked]

Ned Freed wrote:
> I agree. And I'm sorry, but the argument that "people expect DTDs to be
> displayed as text" just doesn't wash -- technical experts (who are capable
> of configuring their agents to do anything they want) may expect this, but
> the average user doesn't know diddly about XML or DTD and doesn't want a 
> bunch of incomprehensible stuff displayed on his or her screen.

Ned, since you co-authored MIME RFCs, could you please give us an explicit  
criteria of text subtypes?   You appear to claim that text subtypes 
have to be readable by casual users.  However, text/css, text/rfc822-headers,
text/vnd.in3d.3dml, text/rtf are already registered.  I do not think 
that they are quite readable by casual users.  On the other hand, Postscript 
programs are application/postscript rather than text/postscript.  Is text/css 
a mistake?  Should XSL become application/xsl-xml rather than text/xsl-xml?

Cheers,

Makoto
-------------------------------------------------------------------------

RFC 2046: defitition of the top-level media type "text"

> 4.1.  Text Media Type
> 
>    The "text" media type is intended for sending material which is
>    principally textual in form.  A "charset" parameter may be used to
>    indicate the character set of the body text for "text" subtypes,
>    notably including the subtype "text/plain", which is a generic
>    subtype for plain text.  Plain text does not provide for or allow
>    formatting commands, font attribute specifications, processing
>    instructions, interpretation directives, or content markup.  Plain
>    text is seen simply as a linear sequence of characters, possibly
>    interrupted by line breaks or page breaks.  Plain text may allow the
>    stacking of several characters in the same position in the text.
>    Plain text in scripts like Arabic and Hebrew may also include
>    facilitites that allow the arbitrary mixing of text segments with
>    opposite writing directions.
> 
>    Beyond plain text, there are many formats for representing what might
>    be known as "rich text".  An interesting characteristic of many such
>    representations is that they are to some extent readable even without
>    the software that interprets them.  It is useful, then, to
>    distinguish them, at the highest level, from such unreadable data as
>    images, audio, or text represented in an unreadable form. In the
>    absence of appropriate interpretation software, it is reasonable to
>    show subtypes of "text" to the user, while it is not reasonable to do
>    so with most nontextual data. Such formatted textual data should be
>    represented using subtypes of "text".

Here is the list of currently registered subtypes of text.

> text            plain                            [RFC1521,Borenstein]
>                 richtext                         [RFC1521,Borenstein]
>                 enriched                                    [RFC1896]
>                 tab-separated-values                   [Paul Lindner]
>                 html                                        [RFC1866]
>                 sgml                                        [RFC1874]
>                 vnd.latex-z                                   [Lubos]
>                 vnd.fmi.flexstor                             [Hurtta]
> 		uri-list				     [Daniel]
> 		vnd.abc					      [Allen]
> 		rfc822-headers                              [RFC1892]
> 		vnd.in3d.3dml				     [Powers]
> 		prs.lines.tag				      [Lines]
> 		vnd.in3d.spot                                [Powers]
>                 css                                         [RFC2318]
>                 xml                                         [RFC2376]
> 		rtf					    [Lindner]
>                 directory                                   [RFC2425]
>                 calendar                                    [RFC2445]
> 		vnd.wap.wml				      [Stark]
> 		vnd.wap.wmlscript			      [Stark]
> 		vnd.motorola.reflex          		     [Patton]

Date: Sat, 17 Jul 1999 17:07:00 -0800 (PST)
From: Ned Freed <[email-masked]>
Subject: RE: Introduction of media types for XML DTDs
To: Terry Allen <[email-masked]>
Cc: [email-masked], [email-masked], [email-masked]
Sender: [email-masked]

> Ned Freed re Larry:
> | > I think there is no justification for "text/xml-dtd" in addition
> | > to "application/xml-dtd", because there is no utility at all
> | > for an unaware recipient to attempt to display a dtd to a
> | > user as if it were text, which is the reason for having a
> | > "text/" top level type in addition to "application/".
> |
> | I agree. And I'm sorry, but the argument that "people expect DTDs to be
> | displayed as text" just doesn't wash -- technical experts (who are capable
> | of configuring their agents to do anything they want) may expect this, but
> | the average user doesn't know diddly about XML or DTD and doesn't want a
> | bunch of incomprehensible stuff displayed on his or her screen.

> Correct.  But in some contexts, the entity serving the resource wants
> it to be displayed as text.  So I can see a case for having both
> text and application, as I believe we do for SGML, of which XML is
> only a profile.

I think the definition of a text subtype for SGML was an error, and as such
I don't want to repeat it with XML.

As for serving out something with the intent of displaying it as text, I don't
think it is the server's business to tell the client how to display something.
The MIME media type model is to label things as to what they are, not how they
are to be handled. If a server wants to give an indication as to how something
is to be handled it should use another mechanism like content-disposition.

				Ned

Date: Sat, 17 Jul 1999 16:19:27 -0700
From: Terry Allen <[email-masked]>
To: [email-masked], [email-masked]
Subject: RE: Introduction of media types for XML DTDs
Cc: [email-masked]
Sender: [email-masked]

Ned Freed re Larry:
| > I think there is no justification for "text/xml-dtd" in addition
| > to "application/xml-dtd", because there is no utility at all
| > for an unaware recipient to attempt to display a dtd to a
| > user as if it were text, which is the reason for having a
| > "text/" top level type in addition to "application/".
| 
| I agree. And I'm sorry, but the argument that "people expect DTDs to be
| displayed as text" just doesn't wash -- technical experts (who are capable
| of configuring their agents to do anything they want) may expect this, but
| the average user doesn't know diddly about XML or DTD and doesn't want a 
| bunch of incomprehensible stuff displayed on his or her screen.

Correct.  But in some contexts, the entity serving the resource wants
it to be displayed as text.  So I can see a case for having both
text and application, as I believe we do for SGML, of which XML is
only a profile.

regards, Terry Allen (who reads DTDs)
Chairman OASIS Regrep TC (which envisions serving DTDs to be read
	as well as to be parsed)

Date: Sat, 17 Jul 1999 13:40:28 -0800 (PST)
From: Ned Freed <[email-masked]>
Subject: RE: Introduction of media types for XML DTDs
To: Larry Masinter <[email-masked]>
Cc: MURATA Makoto <[email-masked]>, [email-masked]
Sender: [email-masked]

> I think there is no justification for "text/xml-dtd" in addition
> to "application/xml-dtd", because there is no utility at all
> for an unaware recipient to attempt to display a dtd to a
> user as if it were text, which is the reason for having a
> "text/" top level type in addition to "application/".

I agree. And I'm sorry, but the argument that "people expect DTDs to be
displayed as text" just doesn't wash -- technical experts (who are capable
of configuring their agents to do anything they want) may expect this, but
the average user doesn't know diddly about XML or DTD and doesn't want a 
bunch of incomprehensible stuff displayed on his or her screen.

				Ned

Date: Sat, 17 Jul 1999 11:30:15 -0700
To: <[email-masked]>
From: Tim Bray <[email-masked]>
Subject: RE: Introduction of media types for XML DTDs
Sender: [email-masked]

At 08:25 AM 7/17/99 PDT, Larry Masinter wrote:
>I think there is no justification for "text/xml-dtd" in addition
>to "application/xml-dtd", because there is no utility at all
>for an unaware recipient to attempt to display a dtd to a
>user as if it were text

Sounds plausible, but empirical evidence is against this position.
Lots of people read DTDs all the time, and in fact since they are
usually composed in monotype with all sorts of indentation and
other pretty-printing apparatus, there is clearly an expectation
that they be displayed. -Tim

From: "Larry Masinter" <[email-masked]>
To: "MURATA Makoto" <[email-masked]>, <[email-masked]>
Subject: RE: Introduction of media types for XML DTDs
Date: Sat, 17 Jul 1999 08:25:02 PDT
Importance: Normal
Sender: [email-masked]

I think there is no justification for "text/xml-dtd" in addition
to "application/xml-dtd", because there is no utility at all
for an unaware recipient to attempt to display a dtd to a
user as if it were text, which is the reason for having a
"text/" top level type in addition to "application/".

Larry
-- 
http://www.parc.xerox.com/masinter

From: MURATA Makoto <[email-masked]>
Date: Sat, 17 Jul 1999 22:30:36 +0900
To: [email-masked]
Subject: Introduction of media types for XML DTDs
Sender: [email-masked]

I believe that we have agreed to introduce media types for XML DTDs
(to be precise, external DTD subsets and external parameter entities),
since they do not parse as XML documents.

I tried to sketch required changes to the current RFC.  Here I introduced
both text/xml-dtd and application/xml-dtd.  One could certainly argue
aginst this choice.  Comments are greatly appreciated.

1) Revision to "3. XML Media types"

>    This document introduces four new media types for XML entities,
>    text/xml, application/xml, text/xml-dtd, and application/xml-dtd.

...

>  The media types text/xml and application/xml can be used for 
> "document entities" or "external parsed entities".  For backward 
> compatibility, they can also be used for "external DTD subsets" or 
> "external parameter entities".  The media types text/xml-dtd and 
> application/xml-dtd can be used for  "external DTD subsetes" or 
> "external parameter entities".  

2) Addition of two subsections for text/xml-dtd and application/xml-dtd
 
> 3.3 Text/xml-dtd Registration
> 
>    MIME media type name: text
> 
>    MIME subtype name: xml-dtd
> 
>    Mandatory parameters: none
> 
>    Optional parameters: charset
>  
>       The charset parameter of text/xml-dtd is handled exactly 
>       the same as that of text/xml.
> 
>    Encoding considerations:
> 
>      This media type may be encoded exactly the same as text/xml.
> 
>    Security considerations:
> 
>       See section 4 below.
> 
>    Interoperability considerations:
> 
>       XML DTDs has proven to be interoperable by DTD authoring 
>       tools and XML WWW browsers among others.
> 
>    Published specification: see [REC-XML]
> 
>    Applications which use this media type:
> 
>       DTD authoring tools handle external DTD subsets as well as external 
>       parameter entities.   XML browsers may also access external DTD subests
>       and external parameter entities.
> 
>    Additional information:
> 
>       Magic number(s): none
> 
>       Although no byte sequences can be counted on to always be present,
>       external DTD subsets and external parameter entities in ASCII-compatible charsets 
(including UTF-8) often
>       begin with hexadecimal 3C 3F 78 6D 6C ("<?xml").  For more
>       information, see Appendix F of [REC-XML].
> 
>       File extension(s): .dtd
>       Macintosh File Type Code(s): "TEXT"
> 
>    Person & email address for further information:
> 
>       Dan Connolly <[email-masked]>
>       Murata Makoto (Family Given) <[email-masked]>
> 
>    Intended usage: COMMON
> 
>    Author/Change controller:
> 
>       The XML specification is a work product of the World Wide Web
>       Consortium's XML Working Group, and was edited by:
> 
>       Tim Bray <[email-masked]>
>       Jean Paoli <[email-masked]>
>       C. M. Sperberg-McQueen <[email-masked]>
> 
>       The W3C, and the W3C XML working group, has change control over
>       the XML specification.
> 
> 
> 
> 3.4 Application/xml-dtd Registration
> 
>    MIME media type name: application
> 
>    MIME subtype name: xml-dtd
> 
>    Mandatory parameters: none
> 
>    Optional parameters: charset
> 
>       The charset parameter of text/xml-dtd is handled exactly 
>       the same as that of text/xml.
> 
>    Encoding considerations:
>
>       The charset parameter of application/xml-dtd is handled exactly 
>       the same as that of application/xml.
> 
>    Security considerations:
> 
>       See section 4 below.
> 
>    Interoperability considerations:
> 
>       XML DTDs has proven to be interoperable by DTD authoring 
>       tools and XML WWW browsers among others.
> 
>    Published specification: see [REC-XML]
> 
>    Applications which use this media type:
> 
>       DTD authoring tools handle external DTD subsets as well as external 
>       parameter entities.   XML browsers may also access external DTD subests
>       and external parameter entities.
> 
>    Additional information:
> 
>       Magic number(s): none
> 
>       Although no byte sequences can be counted on to always be present,
>       external DTD subsets and external parameter entities in ASCII-compatible charsets 
(including UTF-8) often
>       document entities and external parsed entities in ASCII-compatible charsets 
(including UTF-8) often
>       begin with hexadecimal 3C 3F 78 6D 6C ("<?xml"), and those in
>       UTF-16 often begin with hexadecimal FE FF 00 3C 00 3F 00 78 00 6D
>       or FF FE 3C 00 3F 00 78 00 6D 00 (the Byte Order Mark (BOM)
>       followed by "<?xml").  For more information, see Annex F of [REC-
>       XML].
> 
>       File extension(s): .dtd
>       Macintosh File Type Code(s): "TEXT"
> 
>    Person & email address for further information:
> 
>       Dan Connolly <[email-masked]>
>       Murata Makoto (Family Given) <[email-masked]>
> 
>    Intended usage: COMMON
> 
> 
>    Author/Change controller:
> 
>       The XML specification is a work product of the World Wide Web
>       Consortium's XML Working Group, and was edited by:
> 
>       Tim Bray <[email-masked]>
>       Jean Paoli <[email-masked]>
>       C. M. Sperberg-McQueen <[email-masked]>
> 
>       The W3C, and the W3C XML working group, has change control over
>       the XML specification.

3)  Addition of examples in sectino 6

> 6.10 text/xml-dtd with UTF-8 Charset
> 
>    Content-type: text/xml-dtd; charset="utf-8"
> 
>    <?xml version="1.0" encoding="utf-8"?>
> 
>    This is the recommended charset value for use with text/xml-dtd.  Since
>    the charset parameter is provided, MIME and XML processors must treat
>    the enclosed entity as UTF-8 encoded.
>
>
> 
> 6.11 application/xml-dtd with UTF-16 Charset   
> 
>    Content-type: application/xml-dtd; charset="utf-16"
> 
>    {BOM}<?xml version="1.0"?>
> 
>    This is a recommended charset value for use with application/xml-dtd.
>    Since the charset parameter is provided, MIME and XML processors must
>    treat the enclosed entity as UTF-16 encoded.

Cheers,

Makoto
 
Fuji Xerox Information Systems
 
Tel: +81-44-812-7230   Fax: +81-44-812-7231
E-mail: [email-masked]

From: "Larry Masinter" <[email-masked]>
To: "Paul Grosso" <[email-masked]>
Cc: <[email-masked]>
Subject: RE: Media typs and XPointer, XLink, XPath, and XSLT
Date: Tue, 13 Jul 1999 18:24:51 PDT
Importance: Normal
Sender: [email-masked]

the meaning of a fragment identifier is determined by the media
type of the data being pointed into. You've defined it
for XML and HTML. Whether fragment identifiers have any meaning for
any other media type is up to the definition of the media type.

If a type is defined using XML, the type definition can also indicate
"use XML semantics for fragment identifiers", or it can give
any other semantics.

Larry
-- 
http://www.parc.xerox.com/masinter

From: [email-masked]
To: [email-masked]
Date: Tue, 13 Jul 1999 13:31:07 -0400
Subject: Re: Media typs and XPointer, XLink, XPath, and XSLT
Sender: [email-masked]

I'm not sure what you mean by "import other things".  XLink has no mechanism for
specifying the import of other things.  It specifies relationships between
things, but not the semantics of importing.  As an aside, I think there does
need to be a different mechanism for importing things other than external
entities, but that's a different discussion.

There is no information model for how to represent imported things or
transformed things, beit XML or non-XML.

The DOM has no APIs that distinguish between pre or post transform XML
documents, nor pre or post "importing"/including documents.   Even the DOM Level
1 API treats notations as read-only elements, and these only specify an external
thing.  DOM level 2 has a simple text line stating "Creating EntityReference
nodes" will be part of level 2.

Please elaborate on what you mean by importing and what you expect of infoset,
transformations and APIs.

Cheers,
Dave Orchard

"Shane P. McCarron" <[email-masked]> on 07/13/99 06:41:35 AM

Please respond to [email-masked]

To:
cc:   [email-masked]
Subject:  Re: Media typs and XPointer, XLink, XPath, and XSLT

John Cowan wrote:
>
> Rick Jelliffe wrote:
> > I am confused about a related question: I have heard somewhere that
> > the XPointer group was going to make XPointers only valid for pointing
> > into XML documents.  So, for example, it would not be legitimate for
> > an XPointer to point into a WebCGM document or other structured data.  Is
this true?
>
> Since XPointers refer explicitly to element trees with attributes,
> an XPointer into CGM (which is a binary format) wouldn't make
> much sense.  The real issue is whether XPointers can point into
> things like SMIL documents, which "just happen" to be encoded
> in XML.

Certainly from the XHTML perspective, the ability to refer to other XML
grammars via XPointer/XLink is critical.  Imaging an XHTML document that
uses some new element defined against XLink to import SVG graphics into
a page or a SYMM presentation. These are XML grammars, and they should
work.

However, it might also be useful to import other things - like plain
text.  XPointer/XLink needs to work for this as well.  I don't see how
we can limit the scope of the target.  You might need to treat the
imported item as a BLOB (Binary Large Object), but it should still be
imported.  At least, that's my opinion.
--
Shane P. McCarron                  phone: +1 612 434-4431
Testing Research Manager             fax: +1 612 434-4318
                                  mobile: +1 612 799-6942
                                  e-mail: [email-masked]

OSF/1, Motif, UNIX and the "X" device are registered trademarks in
the US and other countries, and IT DialTone and The Open Group are
trademarks of The Open Group.

Date: Tue, 13 Jul 1999 12:02:36 -0500
To: "[email-masked]" <[email-masked]>
From: Paul Grosso <[email-masked]>
Subject: Re: Media typs and XPointer, XLink, XPath, and XSLT
Sender: [email-masked]

At 12:45 1999 07 13 -0400, John Cowan wrote:
>Tim Bray wrote:
>
>> >Paul Grosso wrote:
>> >
>> >> If the resource is XML, the fragment identifier is to be interpreted
>> >> as an XPointer.
>> >
>> >Yes, but what does it mean to "be XML"?  Does that simply mean
>> >"be a well-formed XML document", or is it also required that
>> >the media-type be "application/xml" or "text/xml"?  If the
>> >media-type is "application/vnd.foo-systems.bar", but the format
>> >happens to be well-formed XML, is the fragment ID necessarily
>> >to be interpreted as an XPointer?
>> 
>> How can you possibly know, in this case, whether the resource is WF
>> XML?  The situation seems clear to me:  [prince-of-clarity snipped]
>
>Me too, me too.  But that's not what Paul said.

In the one line you quoted, I was speaking imprecisely.  I think
I stated it clearly several other places several other times
previously, and I just posted another message (that agrees with
you and Tim) that I hopes makes it crystal clear yet once again.

Date: Tue, 13 Jul 1999 13:05:59 -0400
To: [email-masked]
From: "Simon St.Laurent" <[email-masked]>
Subject: Re: Media typs and XPointer, XLink, XPath, and XSLT
Sender: [email-masked]

At 09:41 AM 7/13/99 -0700, Tim Bray wrote:
>How can you possibly know, in this case, whether the resource is WF
>XML?  The situation seems clear to me:  If it's application/xml
>or text/xml, what comes after the # is an xpointer.  If it's
>anything-else/anything-else, look in the RFC for anything-else/anything-else
>to see how fragment identifiers work.  That RFC might say that the 
>media type happens to be XML and it might (or might not, even if it
>happens to be XML) say that fragment identifiers are xpointers.

Which is exactly why I'd like to get xml- into the MIME type identifier
instead of mucking around with RFC lookup, which doesn't work.

XPointers will work with any MIME type that requires its content to be
well-formed XML.  It seems reasonable to identify that fact in the MIME
type to avoid having to check RFCs for fragment identifier information, a
process that isn't even automatable (until we write English-language
parsers, anyway.)

As for non-XPointer fragment identifiers for MIME types based on XML
documents, I can't say I have much sympathy.  If people really want to go
that route, we're going to need something a heck of a lot more
sophisticated than the current MIME type to RFC connection, and maybe at
the point it's time to just plain start over.

Heck, we could come up with an RFC metadata spec that does provide this
information in a readily parseable and easily available format...

Simon St.Laurent
XML: A Primer / Building XML Applications
Inside XML DTDs: Scientific and Technical
Sharing Bandwidth / Cookies
http://www.simonstl.com

Date: Tue, 13 Jul 1999 12:00:51 -0500
To: [email-masked]
From: Paul Grosso <[email-masked]>
Subject: Re: Media typs and XPointer, XLink, XPath, and XSLT
Sender: [email-masked]

At 12:37 1999 07 13 -0400, John Cowan wrote:
>Paul Grosso wrote:
>
>> If the resource is XML, the fragment identifier is to be interpreted
>> as an XPointer.
>
>Yes, but what does it mean to "be XML"?  

For the resource [1] referenced by the URI [1] of the URI-reference [1] 
to have media type [2] "application/xml" or "text/xml".

Section 4.1. Fragment Identifier of [1] says:

   The semantics of a fragment identifier is a property of the data
   resulting from a retrieval action, regardless of the type of URI used
   in the reference.  Therefore, the format and interpretation of
   fragment identifiers is dependent on the media type [RFC2046] of the
   retrieval result.  

[1] http://www.ietf.org/rfc/rfc2396.txt contains definitions
of and/or pointers to definitions of each term.
[2] http://www.ietf.org/rfc/rfc2046.txt

>Does that simply mean
>"be a well-formed XML document", or is it also required that
>the media-type be "application/xml" or "text/xml"?  If the
>media-type is "application/vnd.foo-systems.bar", but the format
>happens to be well-formed XML, is the fragment ID necessarily
>to be interpreted as an XPointer?

No.

Date: Tue, 13 Jul 1999 12:45:59 -0400
From: John Cowan <[email-masked]>
Organization: Lojban Peripheral
To: "[email-masked]" <[email-masked]>
Subject: Re: Media typs and XPointer, XLink, XPath, and XSLT
Sender: [email-masked]

Tim Bray wrote:

> >Paul Grosso wrote:
> >
> >> If the resource is XML, the fragment identifier is to be interpreted
> >> as an XPointer.
> >
> >Yes, but what does it mean to "be XML"?  Does that simply mean
> >"be a well-formed XML document", or is it also required that
> >the media-type be "application/xml" or "text/xml"?  If the
> >media-type is "application/vnd.foo-systems.bar", but the format
> >happens to be well-formed XML, is the fragment ID necessarily
> >to be interpreted as an XPointer?
> 
> How can you possibly know, in this case, whether the resource is WF
> XML?  The situation seems clear to me:  [prince-of-clarity snipped]

Me too, me too.  But that's not what Paul said.

-- 
	John Cowan	http://www.ccil.org/~cowan	[email-masked]
Schlingt dreifach einen Kreis um dies! / Schliesst euer Aug vor heiliger Schau,
Denn er genoss vom Honig-Tau / Und trank die Milch vom Paradies.
			-- Coleridge / Politzer

Date: Tue, 13 Jul 1999 09:41:48 -0700
To: John Cowan <[email-masked]>, [email-masked]
From: Tim Bray <[email-masked]>
Subject: Re: Media typs and XPointer, XLink, XPath, and XSLT
Sender: [email-masked]

At 12:37 PM 7/13/99 -0400, John Cowan wrote:
>Paul Grosso wrote:
>
>> If the resource is XML, the fragment identifier is to be interpreted
>> as an XPointer.
>
>Yes, but what does it mean to "be XML"?  Does that simply mean
>"be a well-formed XML document", or is it also required that
>the media-type be "application/xml" or "text/xml"?  If the
>media-type is "application/vnd.foo-systems.bar", but the format
>happens to be well-formed XML, is the fragment ID necessarily
>to be interpreted as an XPointer?

How can you possibly know, in this case, whether the resource is WF
XML?  The situation seems clear to me:  If it's application/xml
or text/xml, what comes after the # is an xpointer.  If it's
anything-else/anything-else, look in the RFC for anything-else/anything-else
to see how fragment identifiers work.  That RFC might say that the 
media type happens to be XML and it might (or might not, even if it
happens to be XML) say that fragment identifiers are xpointers.

 -Tim

Date: Tue, 13 Jul 1999 12:37:25 -0400
From: John Cowan <[email-masked]>
Organization: Lojban Peripheral
To: [email-masked]
Subject: Re: Media typs and XPointer, XLink, XPath, and XSLT
Sender: [email-masked]

Paul Grosso wrote:

> If the resource is XML, the fragment identifier is to be interpreted
> as an XPointer.

Yes, but what does it mean to "be XML"?  Does that simply mean
"be a well-formed XML document", or is it also required that
the media-type be "application/xml" or "text/xml"?  If the
media-type is "application/vnd.foo-systems.bar", but the format
happens to be well-formed XML, is the fragment ID necessarily
to be interpreted as an XPointer?

-- 
	John Cowan	http://www.ccil.org/~cowan	[email-masked]
Schlingt dreifach einen Kreis um dies! / Schliesst euer Aug vor heiliger Schau,
Denn er genoss vom Honig-Tau / Und trank die Milch vom Paradies.
			-- Coleridge / Politzer

Date: Tue, 13 Jul 1999 09:56:42 -0500
To: [email-masked]
From: Paul Grosso <[email-masked]>
Subject: Re: Media typs and XPointer, XLink, XPath, and XSLT
Sender: [email-masked]

At 14:09 1999 07 13 +0900, MURATA Makoto wrote:
>Having finished my summary, I have one question for clarification.  Did the 
>XML Linking WG want to use XPointer only when the media type is text/xml or 
>application/xml?  Or, did they want to use XPointer for other xml-based
media 
>types, but give up simply because the current media type mechanism cannot 
>specify "This is of the media type "model/foo" which is based on XML"?

If the resource is XML, the fragment identifier is to be interpreted
as an XPointer.

The inverse (and converse, it therefore follows) of that statement is
neither necessarily true nor false.  The XLink WG does not want to prevent 
XPointer from being used in non-XML resources, but it also does not want
to say anything one way or the other because that is outside the scope
of the XLink WG.

Asks Rick Jelliffe:
>I am confused about a related question: I have heard somewhere that the
>XPointer
>group was going to make XPointers only valid for pointing into XML
>documents.
>So, for example, it would not be legitimate for an XPointer to point into a
>WebCGM
>document or other structured data.  Is this true?

No.

>Also, there seems to be paradigm difference between the conventional idea
>of a URL (which fetches some resource) and an XPointer (which points to some
>span in some resource but doesn't necessarily return anything). 

XPointer doesn't necessarily point to a span.  It addresses things
(where things might be many of the objects in an XML tree or possibly
a "span" of such objects).

>I had a bit
>of
>difficulty with this at first, and I suspect that others with HTML
>expectations will
>be the same. Murata-san's question relates to this too:  does an XLink
>always
>return a resource. 

"Return" is a semantic, and XLink's semantics are not finalized.
I don't really know how else to answer your question, as it doesn't
really make sense to me.  XPointer addresses, and XLink (which may
use XPointer) links addressed things.  What is means to link addressed
things is yet a different question.

>If XPointers can only be used with XLinks, 

That is not true.

>does that mean
>that
>XPointers always return a resource too? 

XPointer never return anything.  They address things.

>If the resource returned is
>different from
>a type attribute, is it always an error?

This question isn't answerable as it depends on erroneous assumptions.

Shane P. McCarron says:
>However, it might also be useful to import other things - like plain
>text.  XPointer/XLink needs to work for this as well.  I don't see how
>we can limit the scope of the target.  

XLink should be usable with any addressing mechanism, not just XPointer.
XPointer might be usable to address into non-XML resources, but it is
not up to the XLink WG (or the XPointer spec) to address [pardon the pun]
that issue, so you will not see either XLink or XPointer talk about how
to link into plain text.  How a fragment identifier of a URI-reference
addresses into plain text is up to the "plain text mime type" to decide.
Once that's determined, XLink will automatically work with it (you'd just
give a URI-reference as the value of the locator attribute of the XLink
element).

paul

Date: Tue, 13 Jul 1999 09:58:40 -0400
To: [email-masked]
From: "Simon St.Laurent" <[email-masked]>
Subject: Re: Media typs and XPointer, XLink, XPath, and XSLT
Cc: [email-masked]
Sender: [email-masked]

[I've cross-posted this to [email-masked].  It seems like
it might be a good idea for the XPointer folk to be aware of the MIME type
discussions going on in ietf-xml-mime, and that text/xml and
application/xml may not always remain the only MIME types for XML documents.]

The latest (9 July 1999) XPointer draft states that:
>XPointer defines the meaning of the "selector" or "fragment identifier"
>portion of URIs that locate resources of MIME media types "text/xml" and 
>"application/xml".

At 09:12 AM 7/13/99 -0400, John Cowan wrote (on [email-masked]):

> The real issue is whether XPointers can point into
>things like SMIL documents, which "just happen" to be encoded
>in XML.

This doesn't make sense to me.

First, I can see where 'smarter' SMIL documents might make use of
XLink/XPointer in more sophisticated ways than is presently possible with
their simple href linking.  SMIL 2.0, for instance, might take fuller
advantage of its XML heritage than SMIL 1.0 did.  (If, of course, there
ever is a SMIL 2.0.)

Second, it seems extremely reasonable that other XML documents might well
point into SMIL documents and take advantage of the information stored
there.  While embedding fragments of multimedia presentations may raise
some complex questions, doing something like embedding the closed-caption
information (text) from a SMIL presentation inside another document seems
perfectly reasonable.

In other words, why is this even an issue for the XPointer spec to worry
about?  It might be something that potentially gives application designers
a headache, _if_ they want to present SMIL fragments as multimedia
presentations, but that doesn't seem like something the XPointer standard
itself should care about.

XPointer can work with any kind of XML document.  If the application can't
deal with how that document is supposed to be displayed, it had better have
some alternatives ready.  Not displaying it is one option, displaying it as
text is another, applying a stylesheet is yet another, etc....

Simon St.Laurent
XML: A Primer / Building XML Applications
Inside XML DTDs: Scientific and Technical
Sharing Bandwidth / Cookies
http://www.simonstl.com

Date: Tue, 13 Jul 1999 08:41:35 -0500
From: "Shane P. McCarron" <[email-masked]>
Reply-To: [email-masked]
Organization: The Open Group
CC: [email-masked]
Subject: Re: Media typs and XPointer, XLink, XPath, and XSLT
Sender: [email-masked]

John Cowan wrote:
> 
> Rick Jelliffe wrote:
> > I am confused about a related question: I have heard somewhere that
> > the XPointer group was going to make XPointers only valid for pointing
> > into XML documents.  So, for example, it would not be legitimate for
> > an XPointer to point into a WebCGM document or other structured data.  Is this true?
> 
> Since XPointers refer explicitly to element trees with attributes,
> an XPointer into CGM (which is a binary format) wouldn't make
> much sense.  The real issue is whether XPointers can point into
> things like SMIL documents, which "just happen" to be encoded
> in XML.

Certainly from the XHTML perspective, the ability to refer to other XML
grammars via XPointer/XLink is critical.  Imaging an XHTML document that
uses some new element defined against XLink to import SVG graphics into
a page or a SYMM presentation. These are XML grammars, and they should
work.

However, it might also be useful to import other things - like plain
text.  XPointer/XLink needs to work for this as well.  I don't see how
we can limit the scope of the target.  You might need to treat the
imported item as a BLOB (Binary Large Object), but it should still be
imported.  At least, that's my opinion.
--
Shane P. McCarron                  phone: +1 612 434-4431
Testing Research Manager             fax: +1 612 434-4318
                                  mobile: +1 612 799-6942
                                  e-mail: [email-masked]

OSF/1, Motif, UNIX and the "X" device are registered trademarks in
the US and other countries, and IT DialTone and The Open Group are
trademarks of The Open Group.

Date: Tue, 13 Jul 1999 09:12:20 -0400
From: John Cowan <[email-masked]>
Organization: Lojban Peripheral
To: [email-masked]
Subject: Re: Media typs and XPointer, XLink, XPath, and XSLT
Sender: [email-masked]

Rick Jelliffe wrote:
> I am confused about a related question: I have heard somewhere that
> the XPointer group was going to make XPointers only valid for pointing
> into XML documents.  So, for example, it would not be legitimate for
> an XPointer to point into a WebCGM document or other structured data.  Is this true?

Since XPointers refer explicitly to element trees with attributes,
an XPointer into CGM (which is a binary format) wouldn't make
much sense.  The real issue is whether XPointers can point into
things like SMIL documents, which "just happen" to be encoded
in XML.

-- 
	John Cowan	http://www.ccil.org/~cowan	[email-masked]
Schlingt dreifach einen Kreis um dies! / Schliesst euer Aug vor heiliger Schau,
Denn er genoss vom Honig-Tau / Und trank die Milch vom Paradies.
			-- Coleridge / Politzer

From: "Rick Jelliffe" <[email-masked]>
To: <[email-masked]>
Subject: Re: Media typs and XPointer, XLink, XPath, and XSLT
Date: Tue, 13 Jul 1999 14:34:57 +0800
Sender: [email-masked]

 From: MURATA Makoto <[email-masked]>
 >
> Having finished my summary, I have one question for clarification.  Did
the
> XML Linking WG want to use XPointer only when the media type is text/xml
or
> application/xml?  Or, did they want to use XPointer for other xml-based
media
> types, but give up simply because the current media type mechanism cannot
> specify "This is of the media type "model/foo" which is based on XML"?

I am confused about a related question: I have heard somewhere that the
XPointer
group was going to make XPointers only valid for pointing into XML
documents.
So, for example, it would not be legitimate for an XPointer to point into a
WebCGM
document or other structured data.  Is this true?

Also, there seems to be paradigm difference between the conventional idea
of a URL (which fetches some resource) and an XPointer (which points to some
span in some resource but doesn't necessarily return anything). I had a bit
of
difficulty with this at first, and I suspect that others with HTML
expectations will
be the same. Murata-san's question relates to this too:  does an XLink
always
return a resource. If XPointers can only be used with XLinks, does that mean
that
XPointers always return a resource too? If the resource returned is
different from
a type attribute, is it always an error?

Rick Jelliffe

From: MURATA Makoto <[email-masked]>
Date: Tue, 13 Jul 1999 14:09:37 +0900
To: [email-masked]
Subject: Media typs and XPointer, XLink, XPath, and XSLT
Sender: [email-masked]

Paul Grosso wrote:

> I'm not nearly an expert in this area as you are, so I'm a bit 
> nervous answering, but I'm the one that has been championing that 
> language in XPointer (and XLink) based on an understanding of things 
> that is different from what you say above.

Thanks for your flattering comments, but I am not a real expert.  Probably 
nobody know all of XLink, XPointer, XML, MIME, conneg, SMTP, 
HTTP, etc.  I certainly do not, as You and Tim proved.

Just in case some participants do not know XLink, XPointer, XSLT, 
and XPath, let me give a very rough overview.  XPointer allows you to say 
"Give me the second <Para> of the third <Section> of this XML document".  
Since XPointer is a string, you can use it as a fragment identifier.

XLink provides allows you to specify links with XML elements.  Such 
links may use XPointer to specify ends of links.  But XLink can also 
reference to non-XML data.  Thus, even if a link is expressed in XLink, 
we do not really know whether its ends are XPointer or not.  As a special case, 
if bare names are used as fragment identifiers, they are interpreted as HTML 
fragment identifiers or XPointer depending on the media type.   Since the 
semantics of bare name XPointers is identical to that of HTML fragment identifiers, 
this flexibility does not cause any problems.

XSLT is a transformation language which transforms XML to XML or HTML.  
An XSLT stylesheet often contain rules such as "For each <para>, generate 
a <p> element" or even "For each <para> below each <section>, generate ...".
Thus, XSLT needs something similar to XPointer.  XPath was created to 
capture common mechanisms between XSLT and XPointer.  XPointer and XSLT can 
be considered as extensions of XPath.

Unlike XPointer, neither the XPath nor XSLT specification mention media 
types text/xml and application/xml.   This looks reasonable, since the XSLT 
engine just knows that it is transforming XML.

Note: there is an issue about "Multiple Source Documents" of XSLT.  The 
subsection for the "document" function has an interesting issue as below:

	Issue (document-media-type): What are legal media types for the 
	resource referenced by document()? For example, what happens if 
	referencing the URI returns data with media type text/plain?

Having finished my summary, I have one question for clarification.  Did the 
XML Linking WG want to use XPointer only when the media type is text/xml or 
application/xml?  Or, did they want to use XPointer for other xml-based media 
types, but give up simply because the current media type mechanism cannot 
specify "This is of the media type "model/foo" which is based on XML"?

Cheers,

Makoto
 
Fuji Xerox Information Systems
 
Tel: +81-44-812-7230   Fax: +81-44-812-7231
E-mail: [email-masked]

Date: Mon, 12 Jul 1999 10:14:26 -0700
To: MURATA Makoto <[email-masked]>, [email-masked]
From: Tim Bray <[email-masked]>
Subject: Re: xml-mime status?
Sender: [email-masked]

At 07:24 PM 7/12/99 +0900, MURATA Makoto wrote:
>>XPointer defines the meaning of the "selector" or "fragment identifier" 
>>portion of URIs that locate resources of MIME media types "text/xml" 
>>and "application/xml".
>
>I have a question.  Why do we have to use media types here?  If an XML 
>document contains a link which takes advantage of XPointer, we just know 
>that the URI references to an XML document and thus do not have to be 
>notified by XML media types.  

No.  Because of the following:
1. You can't tell what the media type of a resource is without getting it
2. Xpointers are not sufficiently distinguishable from all other types of
   fragment identfiers by syntax alone

So you have to ascertain the media type of the resource to determine
whether XPointer is the appropriate fragment identifier syntax. -Tim

Date: Mon, 12 Jul 1999 10:58:43 -0500
To: [email-masked]
From: Paul Grosso <[email-masked]>
Subject: Re: xml-mime status?
Sender: [email-masked]

At 19:24 1999 07 12 +0900, MURATA Makoto wrote:
>2) Announcement of a new draft of XPointer (http://www.w3.org/TR/WD-xptr)
>
>>XPointer defines the meaning of the "selector" or "fragment identifier" 
>>portion of URIs that locate resources of MIME media types "text/xml" 
>>and "application/xml".
>
>I have a question.  Why do we have to use media types here?  If an XML 
>document contains a link which takes advantage of XPointer, we just know 
>that the URI references to an XML document and thus do not have to be 
>notified by XML media types.  

I'm not nearly an expert in this area as you are, so I'm a bit 
nervous answering, but I'm the one that has been championing that 
language in XPointer (and XLink) based on an understanding of things 
that is different from what you say above.  

My understanding is that the interpretation of the fragment identifier 
in URI-references (RFC 2396) is determined by the media type of the 
resource referenced by the URI in the URI-reference.  It is *not* the 
case that any fragment identifer in any URI-reference *embedded in* an 
XML resource is necessarily an XPointer.  Also, it is not always the
case that one can look at a URI-reference and tell that the fragment
identifier "takes advantage of XPointer."  Finally, though the fragment
identifier of a URI-reference into an XML resource must be an XPointer,
there is nothing that prevents XPointer from being used as the syntax
for a fragment identifier into a non-XML resource (i.e., the converse
of "if the resource is XML, the fragment identifier is an XPointer"
is not necessarily true). 

So I'd say that is why XPointer must and should mention media types, and
I'd disagree with your statement "If an XML document contains a link which 
takes advantage of XPointer, we just know that the URI references an XML 
document...."

I hope I will be corrected if I'm mistaken.

paul

From: MURATA Makoto <[email-masked]>
Date: Mon, 12 Jul 1999 19:24:07 +0900
To: [email-masked]
Subject: Re: xml-mime status?
Sender: [email-masked]

Simon St.Laurent wrote:
> The last message on this list was 6/2/99.  Is there any activity going on,
> or have we all taken the summer (or winter, southern hemisphere) off?

Two things recently happened.

1) Announcement of the first draft of XPath (http://www.w3.org/TR/xpath)

This specification does not reference to media types.

2) Announcement of a new draft of XPointer (http://www.w3.org/TR/WD-xptr)

>XPointer defines the meaning of the "selector" or "fragment identifier" 
>portion of URIs that locate resources of MIME media types "text/xml" 
>and "application/xml".

I have a question.  Why do we have to use media types here?  If an XML 
document contains a link which takes advantage of XPointer, we just know 
that the URI references to an XML document and thus do not have to be 
notified by XML media types.  

Makoto
 
Fuji Xerox Information Systems
 
Tel: +81-44-812-7230   Fax: +81-44-812-7231
E-mail: [email-masked]

Date: Sun, 11 Jul 1999 18:41:48 -0400
To: [email-masked]
From: "Simon St.Laurent" <[email-masked]>
Subject: xml-mime status?
Sender: [email-masked]

The last message on this list was 6/2/99.  Is there any activity going on,
or have we all taken the summer (or winter, southern hemisphere) off?

I think all the questions we've examined are still worth solving.

Simon St.Laurent
XML: A Primer / Building XML Applications
Inside XML DTDs: Scientific and Technical
Sharing Bandwidth / Cookies
http://www.simonstl.com