Subject: RE: Question: URI reference and media type in HTML/XML
From: Bert Bos <[email-masked]>
To: <[email-masked]>
Date: Sun, 31 Oct 1999 16:04:26 -0500 (EST)
List-Id: <ietf-xml-mime.imc.org>

[> > = quote from MURATA Makoto]

Gavin Thomas Nicol writes:
> > 	<?xml-stylesheet type="text/xml" href="#style1"?>
> > 
> > We have agreed that fragments do not have media types.  What will  
> > happen to such media types combined with fragment identifiers?
> > Should they be simply ignored?
> 
> This is another case where the fragment inherits the media type.
> Again, the entire document must be fetched (as text/xml), and then
> the fragment identifier resplved in terms of that. With the example
> above, the fragment shoould be resolved in the resource containing the
> reference.

I'm not sure. Makoto poses a very interesting question. Either this
example is an exception to the rule, or there is something wrong with
(this use of) the xml-stylesheet PI.

In this example, there is no sense in putting the type of the document
in the PI, because we must have already established the type of the
document in order to understand the PI.

What we don't know yet, is what type the style sheet is. If it is
embedded, it is probably CSS or XSL, but how do we find out which?
Heuristics will work in this case, of course, but that is not a
scalable solution. It seems to me that we have no other place to put
the type of the fragment than on the PI...

Bert
-- 
  Bert Bos                                ( W 3 C ) http://www.w3.org/
  http://www.w3.org/people/bos/                              W3C/INRIA
  [email-masked]                             2004 Rt des Lucioles / BP 93
  +33 (0)4 92 38 76 92            06902 Sophia Antipolis Cedex, France

Reply-To: <[email-masked]>
From: "Gavin Thomas Nicol" <[email-masked]>
To: <[email-masked]>
Subject: RE: Question: URI reference and media type in HTML/XML
Date: Fri, 29 Oct 1999 08:07:53 -0400
Importance: Normal
Sender: [email-masked]

> 	<?xml-stylesheet type="text/xml" href="#style1"?>
> 
> We have agreed that fragments do not have media types.  What will  
> happen to such media types combined with fragment identifiers?
> Should they be simply ignored?

This is another case where the fragment inherits the media type.
Again, the entire document must be fetched (as text/xml), and then
the fragment identifier resplved in terms of that. With the example
above, the fragment shoould be resolved in the resource containing the
reference.

From: MURATA Makoto <[email-masked]>
Date: Fri, 29 Oct 1999 13:13:10 +0900
To: [email-masked]
Subject: Question: URI reference and media type in HTML/XML
Sender: [email-masked]

HTML and XML provide language constructs that specify both URI 
references and media types.  For example, an example (see below) 
in 2.7 "Embedding Stylesheets" of the XSLT PR [1] specifies a fragment 
identifier and "text/xml".

	<?xml-stylesheet type="text/xml" href="#style1"?>

We have agreed that fragments do not have media types.  What will  
happen to such media types combined with fragment identifiers?
Should they be simply ignored?

[1] http://www.w3.org/TR/xslt#section-Embedding-Stylesheets

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

From: MURATA Makoto <[email-masked]>
Date: Fri, 29 Oct 1999 13:10:55 +0900
To: [email-masked]
Subject: Agreement: Fragments do not have media types
Sender: [email-masked]

Having read recent discussion, I think that we reached an greement.  
Fragments do not have media types.

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

Reply-To: <[email-masked]>
From: "Gavin Thomas Nicol" <[email-masked]>
To: <[email-masked]>
Subject: RE: MIME types and fragment identifiers in HTML and XML
Date: Thu, 28 Oct 1999 22:50:41 -0400
Importance: Normal
Sender: [email-masked]

> That part is certainly true. To process the fragment (client-side
> specialiser) one must first retrieve and dispatch the entire document,
> according to it's media type as a whole, before then being
> able to point to or position oneself at the particular fragment in
question.

Right. This is fundamentally different to sub-resource addressing.

Date: Thu, 28 Oct 1999 02:36:24 +0200
From: Chris Lilley <[email-masked]>
Organization: W3C
To: Larry Masinter <[email-masked]>
CC: MURATA Makoto <[email-masked]>, [email-masked]
Subject: Re: MIME types and fragment identifiers in HTML and XML
Sender: [email-masked]

Larry Masinter wrote:
> 
> > I still have fundamental questions.  Do fragments identified by fragment
> > identifiers have media types?  If so, who specifies the media types?
> 
> We're making up things about fragment identifiers. The only existing
> ones are the ones that work with HTML, 

Actually there are others, including ones that work with SMIL, SVG, and
WebCGM.

> and *those* certainly don't
> identify things with media types. 

That part is certainly true. To process the fragment (client-side
specialiser) one must first retrieve and dispatch the entire document,
according to it's media type as a whole, before then being able to point
to or position oneself at the particular fragment in question.

--
Chris

Date: Wed, 27 Oct 1999 09:51:45 -0400
From: John Cowan <[email-masked]>
Organization: Reuters Health Information
To: MURATA Makoto <[email-masked]>
CC: [email-masked]
Subject: Re: MIME types and fragment identifiers in HTML and XML
Sender: [email-masked]

MURATA Makoto wrote:
> 
> I still have fundamental questions.  Do fragments identified by fragment
> identifiers have media types?

No.  The purpose of a media type (type, subtype, and parameters) is to give
just enough information to make a bunch of bytes (whether in a file or on
a wire) dispatchable to the appropriate interpreter.  To interpret a
fragment, one has to have already determined the media type of the context.

-- 

John Cowan	http://www.reutershealth.com		[email-masked]
Schlingt dreifach einen Kreis vom dies / Schliess eurer Aug vor heiliger Schau
Den er genoss vom Honig-Tau / Und trank die Milch vom Paradies.
		-- Coleridge (tr. Politzer)

From: Miles Sabin <[email-masked]>
To: [email-masked]
Subject: RE: MIME types and fragment identifiers in HTML and XML
Date: Wed, 27 Oct 1999 11:54:16 +0100
Sender: [email-masked]

Larry Masinter wrote,
> We're making up things about fragment identifiers. The
> only existing ones are the ones that work with HTML, 
> and *those* certainly don't identify things with media 
> types.
<snip/>
> I don't think fragments can or should have media 
> types. Content-type media types in MIME are for 
> identifying the application semantics intended by an 
> entire message body, and not for denoting anything 
> about the types of components of that body.

I agree that as things stand there are no media types
associated with fragments. But, for all that, I think
that Makoto's plea for something of this sort is
reasonable: where a resource is composite and has a
named constituent which could be treated as having
a media type distinct from that of it's enclosing
resource if taken in isolation, it'd be nice if that
media type were available.

One option to support this might be to extend media 
types to allow for composite types (tho' I don't really 
see how that could be made to work in practice). Another 
option might be an HTTP extension: either a 'fragment'
GET, or more simply, a Fragment: request header. With 
the latter we might replace,

  GET /foo.xml#stylesheet HTTP/1.1
  Host: foo.bar.com

with,

  GET /foo.xml HTTP/1.1
  Host: foo.bar.com
  Fragment: stylesheet

and expect to get back an entity with with a
text/xml-xsl (or whatever it is) media type.

Hmm ... actully, looking at this, it strikes me that
there might be some overlap with the CONNEG stuff?

Cheers,

Miles

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

From: "Larry Masinter" <[email-masked]>
To: "MURATA Makoto" <[email-masked]>, <[email-masked]>
Subject: RE: MIME types and fragment identifiers in HTML and XML
Date: Tue, 26 Oct 1999 19:34:27 PDT
Importance: Normal
Sender: [email-masked]

> I still have fundamental questions.  Do fragments identified by fragment 
> identifiers have media types?  If so, who specifies the media types?

We're making up things about fragment identifiers. The only existing
ones are the ones that work with HTML, and *those* certainly don't
identify things with media types. If you point at an 
<H1><A NAME="ab">This is a heading marked 'ab'</A></H1>, what is
the type of the fragment inside the H1? It's not 'text/html'.

By extension, I don't think fragments have media types. That's why
they're fragments.

> You appear to argue that the type info specified by HTML or XML link 
> constructs may be used to override the media type of an HTML entity.  As 
> for fragments, are you saying that the type info specified by HTML or XML 
> link constructs *always* provides the media type?  

I don't think fragments can or should have media types. Content-type
media types in MIME are for identifying the application semantics
intended by an entire message body, and not for denoting anything
about the types of components of that body.

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

From: MURATA Makoto <[email-masked]>
Date: Wed, 27 Oct 1999 11:26:50 +0900
To: <[email-masked]>
Subject: Re: MIME types and fragment identifiers in HTML and XML
Sender: [email-masked]

Larry,

Thank you for your detailed comments and corrections.

I still have fundamental questions.  Do fragments identified by fragment 
identifiers have media types?  If so, who specifies the media types?

You appear to argue that the type info specified by HTML or XML link 
constructs may be used to override the media type of an HTML entity.  As 
for fragments, are you saying that the type info specified by HTML or XML 
link constructs *always* provides the media type?  

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]>
Cc: <[email-masked]>
Subject: RE: MIME types and fragment identifiers in HTML and XML
Date: Sun, 24 Oct 1999 11:36:04 PDT
Importance: Normal
Sender: [email-masked]

One more reference to include: the XPointer draft claims to
define what fragment identifiers for XML content-type are supposed
to be, but isn't referenced in your analysis

http://www.w3.org/1999/07/WD-xptr-19990709 says:

  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".

> 1. URI and URI reference
>
> A URI does not have a fragment identifier, but a URI reference (as defined by
> RFC 2396) may have a fragment identifier.  (Note: HTML and XML very often
> say "URI" when it should actually say "URI reference".).

To be fair, the terminology has changed over time; the term "URI" is
used ambiguously in various documents.

> 1) URI
>
> An entity is returned by some protocol  (here, the word "entity" is used as
> in RFC 2616).  The protocol should provide some mechanism for transmitting or
> inferring media type. In HTTP and email, this is done explicitly with the
> 'content-type' header.

Not all resources identified by a URI have a way of obtaining an
'entity'. HTTP does, and so "http:" URLs can talk about entities
being returned, but "mailto:" has no corresponding entity. It isn't
necessary for there to be a 'protocol' that 'returns' entities, either;
for example, the "cid" URL scheme makes reference to content of
MIME messages without a specified protocol, but it would be possible
to use a fragment identifier with a "cid" URL.

Those URIs which don't have a way of obtaining entities also don't allow
fragment identifiers.

Your use of 'email' here is somewhat confusing, because there is often no
appropriate URI to use for an email message. However, other protocols
use MIME content-type for content identification, including IMAP and
IPP.

> 2) URI reference
>
> A URI is first constructed.

I'm not sure "constructed" is the right word here, but I'm not
sure what you meant.

> An entity is returned or accessed interactively
> by some protocol.  The protocol should indicate the media type of the
> entity.
> Then, the user agent for this media type may extract or locate some fragment
> of this entity by using the fragment identifier.

I don't think "user agent" is the right term here; it is the
"interpreter for this media type"; in some cases, the interpreter
is part of a user agent, and in others, it's part of some other
function.

> The protocol does not indicate the media type for that fragment.

You're saying that fragments don't have media types themselves, I think.

>  Thus, it
> does not have content types, unless the fragment contains some other way of
> specifying media types. (For example, RFC 2397, "data" URL scheme, provides
> a way of including MIME content-type along with encoded data.)

I think you're trying to argue that fragments don't, in general, have
media types, even when there are some cases where compound objects have
embedded data which *does* have a media type. The data URL scheme is
certainly one kind of counterexample, but I'm not sure I would recommend
it.

> 2.  Media types specified by HTML or XML language constructs
>
> HTML and XML provides many constructs which specifies both an URI reference
> and a media type.  The HTML and XML specifications are rather silent about
> the intended semantics.

> 1) URI
>
> One could argue that the specified media type is used when the protocol does
> not indicate the content type of the entity.  One could even argue that
> the specified media type always override the content type indicated by the
> protocol.  (Note: Many implementations fail to indicate media types
> correctly.)
>
> One could also argue that the specified media type is used to predict or
> restrict the content type of the desired entity.  That is, if an A
> link contains a 'type' attribute and the resulting URI returns an
> entity with a different content-type, then an error has occurred.

> This isn't so different as getting a '404 not found'.  Something
> happened which wasn't expected. There are various ways of recovering,
> but any attempt to override one piece of MIME data with something
>  that's "fresher" and more authoritative seems wrong.

I think I sent something like this earlier, but it came out wrong.
The problem when you have conflicting sources of information ("what
is the MIME type of this data") that you *do* want to select the
one that is fresher and more authoritative, but that there are cases
where the data associated with the URI itself is likely to be more
authoritative (e.g., with some FTP sources) and other cases where
the data associated with the entity is more authoritative (e.g., with
a recently maintained HTTP server.)

This is a design issue with HTML and (I suppose) XLink. Perhaps
there needs to be more than one way of associating a content-type
with a URI, one of which says "override content-type" and another
of which says "default content-type".

Note that even MIME-compliant protocols that normally associate
content-type with data can disclaim responsibility for it by,
say, using content-type: application/octet-stream. We might have
some theory of overriding, where text/xml would override
application/octet-stream and text/html would override text/xml
(specific overrides generic).

> 2) URI reference
>
> If a construct in HTML or XML specifies a URI reference containing a fragment
> identifier, the construct also specifies a media type, and the protocol
> indicates the content type of the entity, what will happen?
>
> One could argue that the specified media type is used for the desired
> fragment, unless the fragment contains some other way of specifying media
types.

I don't understand this case ('the fragment contains some other way...')

> One could also argue that the fragment must indicate the media type and that
> it must coincide with the media type specified by the HTML or XML
> construct (fragment).

This is unreasonable, since it isn't compatible with normal usage
where fragments are used without explicit media type.
> If the fragment does not explicitly specify the same media type, an error has
> occurred.

Perhaps you mean "if the fragment explicity specifies a media type but
it isn't the same", since not specifying a media type shouldn't be an error.

I believe that there is a generic form of a "fragment" which is
"an uninterpreted name", and that we should expect that most media
types that allow fragments have a way of looking up named components.
This would correspond to <A NAME=..> names in HTML and IDs in XML.
We should expect that other media types that have fragments will
also define named components, too.

I'd like this definition of fragment identifiers to be more specific
about encoding, though; currently it is common practice to use
spaces in fragment identifiers, for example, rather than %20 encoding
them.

> [1] HTML 4.0
>
> (http://www.w3.org/TR/html40/types.html#h-6.7)
>
> > 6.7 Content types (MIME types)
> >
> > Note. A "media type" (defined in [RFC2045] and [RFC2046]) specifies
> > the nature of a linked resource. This specification employs the term
> > "content type" rather than "media type" in accordance with current
> > usage. Furthermore, in this specification, "media type" may refer to
> > the media where a user agent renders a document.
> >
> > This type is represented in the DTD by %ContentType;.
> >
> > Content types are case-insensitive.
> >
> > Examples of content types include "text/html", "image/png",
> > "image/gif", "video/mpeg", "audio/basic", "text/tcl",
> > "text/javascript", and "text/vbscript". For the current list of
> > registered MIME types, please consult [MIMETYPES].
> > Note. The content type "text/css", while not currently registered with
> > IANA, should be used when the linked resource is a [CSS1] style sheet.
> http://www.w3.org/TR/REC-html40/present/styles.html#h-14.2.3

I've been trying to deal with issues around this paragraph in the
HTML working group; certainly, since "text/css" has been registered,
this paragraph should change.

From: [email-masked]
To: <[email-masked]>
Subject: Keep in touch.
Date: Fri, 22 Oct 1999 02:55:08 -0700
Sender: [email-masked]

Want to keep in touch with old friends from school?
The Gradfinder website is the perfect place to do just that.

On Gradfinder you can search for friends, add your
current contact info, a current photo, and details
about what you are up to these days. You can update
your info at any time after that. All changes happen
immediately. There are also message boards you can use
to help organize reunions. You can use our photo album
wizard to create online albums to share with friends
and family.

There are currently over 100,000 schools listed from
grade 1 to university from 60 countries around the world.

This service is free so check it out!

This site can be found at:

http://www.gradfinder.com

From: MURATA Makoto <[email-masked]>
Date: Thu, 21 Oct 1999 16:39:31 +0900
To: <[email-masked]>
Subject: MIME types and fragment identifiers in HTML and XML
Sender: [email-masked]

Here is my understanding of MIME types and fragment identifiers.  I think 
that the semantics of "type" attribute in HTML 4.0 [1] and "Associating 
Style Sheets with XML documents " [2] are unclear.

1. URI and URI reference

A URI does not have a fragment identifier, but a URI reference (as defined by 
RFC 2396) may have a fragment identifier.  (Note: HTML and XML very often 
say "URI" when it should actually say "URI reference".).  

1) URI

An entity is returned by some protocol  (here, the word "entity" is used as 
in RFC 2616).  The protocol should provide some mechanism for transmitting or 
inferring media type. In HTTP and email, this is done explicitly with the  
'content-type' header.  

2) URI reference

A URI is first constructed.  An entity is returned or accessed interactively 
by some protocol.  The protocol should indicate the media type of the entity.  
Then, the user agent for this media type may extract or locate some fragment 
of this entity by using the fragment identifier.

The protocol does not indicate the media type for that fragment.   Thus, it 
does not have content types, unless the fragment contains some other way of 
specifying media types. (For example, RFC 2397, "data" URL scheme, provides 
a way of including MIME content-type along with encoded data.)

2.  Media types specified by HTML or XML language constructs

HTML and XML provides many constructs which specifies both an URI reference 
and a media type.  The HTML and XML specifications are rather silent about 
the intended semantics.

1) URI

One could argue that the specified media type is used when the protocol does 
not indicate the content type of the entity.  One could even argue that 
the specified media type always override the content type indicated by the 
protocol.  (Note: Many implementations fail to indicate media types correctly.) 

One could also argue that the specified media type is used to predict or 
restrict the content type of the desired entity.  That is, if an A link contains 
a 'type' attribute and the resulting URI returns an entity with a different 
content-type, then an error has occurred.

This isn't so different as getting a '404 not found'.  Something happened which 
wasn't expected. There are various ways of recovering, but any attempt to override 
one piece of MIME data with something that's "fresher" and more authoritative 
seems wrong.

2) URI reference

If a construct in HTML or XML specifies a URI reference containing a fragment 
identifier, the construct also specifies a media type, and the protocol  
indicates the content type of the entity, what will happen?

One could argue that the specified media type is used for the desired fragment, 
unless the fragment contains some other way of specifying media types.

One could also argue that the fragment must indicate the media type and that 
it must coincide with the media type specified by the HTML or XML construct (fragment).  
If the fragment does not explicitly specify the same media type, an error has 
occurred.

[1] HTML 4.0

(http://www.w3.org/TR/html40/types.html#h-6.7)

> 6.7 Content types (MIME types)
> 
> Note. A "media type" (defined in [RFC2045] and [RFC2046]) specifies
> the nature of a linked resource. This specification employs the term
> "content type" rather than "media type" in accordance with current
> usage. Furthermore, in this specification, "media type" may refer to
> the media where a user agent renders a document.
> 
> This type is represented in the DTD by %ContentType;.
> 
> Content types are case-insensitive.
> 
> Examples of content types include "text/html", "image/png",
> "image/gif", "video/mpeg", "audio/basic", "text/tcl",
> "text/javascript", and "text/vbscript". For the current list of
> registered MIME types, please consult [MIMETYPES].
> 
> Note. The content type "text/css", while not currently registered with
> IANA, should be used when the linked resource is a [CSS1] style sheet.

http://www.w3.org/TR/REC-html40/present/styles.html#h-14.2.3

> 14.2.3 Header style information: the STYLE element
> 
> <!ELEMENT STYLE - - %StyleSheet        -- style info -->
> <!ATTLIST STYLE
>   %i18n;                               -- lang, dir, for use with title --
>   type        %ContentType;  #REQUIRED -- content type of style language --
>   media       %MediaDesc;    #IMPLIED  -- designed for use with these media --
>   title       %Text;         #IMPLIED  -- advisory title --
>   >
> 
> 
> Start tag: required, End tag: required
> 
> Attribute definitions
> 
> type = content-type [CI] 
> 
> This attribute specifies the style sheet language of the element's
> contents and overrides the default style sheet language. The style
> sheet language is specified as a content type (e.g.,
> "text/css"). Authors must supply a value for this attribute; there is
> no default value for this attribute.
> 

[2] Associating Style Sheets with XML documents

http://www.w3.org/TR/xml-stylesheet/

>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, with the exception of the alternate
>pseudo-attribute. If alternate="yes" is specified, then the processing
>instruction has the semantics of <LINK REL="alternate stylesheet">
>instead of <LINK REL="stylesheet">.

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

Reply-To: <[email-masked]>
From: "Gavin Thomas Nicol" <[email-masked]>
To: "'Chris Lilley'" <[email-masked]>, "'Larry Masinter'" <[email-masked]>
Cc: "'Bert Bos'" <[email-masked]>, <[email-masked]>
Subject: RE: Media types for XSL stylesheets
Date: Sun, 17 Oct 1999 10:37:52 -0400
Importance: Normal
Sender: [email-masked]

> Who is the "vendor" of TCL?

Scriptics.

Reply-To: <[email-masked]>
From: "Gavin Thomas Nicol" <[email-masked]>
To: "'MURATA Makoto'" <[email-masked]>, "'James Clark'" <[email-masked]>
Cc: <[email-masked]>
Subject: RE: Media types for XSL stylesheets
Date: Sun, 17 Oct 1999 10:35:54 -0400
Importance: Normal
Sender: [email-masked]

> I think that text/xml is not appropriate for XSLT since an 
> XSLT stylesheet 
> is not readable by casual users.
> 
> [1] http://www.imc.org/ietf-xml-mime/mail-archive/msg00203.html 

Agreed. In addition, it is truly application-specific.

Date: Tue, 12 Oct 1999 20:45:37 +0200
From: Chris Lilley <[email-masked]>
To: Larry Masinter <[email-masked]>
CC: Bert Bos <[email-masked]>, [email-masked]
Subject: Re: Media types for XSL stylesheets
Sender: [email-masked]

Larry Masinter wrote:
> My guess is that the registration would push back and suggest
> registering them as "application" and possibly as faceted
> "application/vnd.ms-vbscript", "application/vnd.tcl".

Who is the "vendor" of TCL?
> 
> > That leads to another issue: MIME type are not only used to get the
> > interpretation started, but also to negotiate capabilities between a
> > client and a server, e.g., in HTTP. In that context, sending a
> > document with embedded XSL to a client that has indicated not being
> > able to handle XSL is not very smart.

True, although if it couldn't, the server would need to be smart to
strip out the XSL (or indeed, to pre-process it on the server). This is
where a reference rather than explicit content can be helpful - the
script is requested in a separate request, and can be content
negotiated.

> MIME types aren't used effectively for HTTP negotiation; the use
> of "Accept" headers has proven unwieldy.

Yes, the early browsers didn't "get it" and sent the same string
regardless of the request; the adoption of plug-in architectures did not
produce any change in the Accept header, and more imporantly, the bulk
of content authors are no longer in control of the servers they use, and
so cannot add new MIME types or configuration options such as qs
factors. Which, of course, not only calls into question coneg but also
the use of MIME types itself.

However, conneg based on Accept can still be useful today - it is more
robust and scalable than recognising user agent identification strings,
for example - and is used on the W3C site to send a PNG (if the client
can accept it) or a GIF (if not).

> We're still looking for
> some other kind of capability/profile mechanism that would be suitable.
> The CONNEG work and the continuing CCPP work in W3C will hopefully
> yield a workable mechanism.

Yes. One thing that would help would be a standard resource description
which could be uploaded (users can still upload files) along with the
actual content, and would affect only the listed resources. That might
allow more flexible content negotiation without server reconfiguration,
cgi scripts, or servlets.

> > In other words, that document with its embedded XSL needs not just a
> > MIME type for its first byte, but also a description (a "profile") of
> > the other capabilities a client needs. That would be something like a
> > CC/PP( http://www.w3.org/Mobile/CCPP/ ) profile, I assume, and inside
> > that there *would* be an entry that says "application/xsl" (or whatever
> > the MIME type will be).
> 
> It isn't necessary to have a MIME type to talk about a capability.
> That is, you could have a feature which is "able to interpret XSL style"
> without registering "application/xsl".

True. There are other alternatives to MIME types.

> The recognition that MIME labelling is insufficient for fine-grained
> description of recipient capabilities or document profiles was the
> foundation of the CONNEG work; it seems likely that CCPP can use the
> CONNEG registry and a superset of the semantics of CONNEG feature
> sets, although likely with an XML (RDF?) based syntax for feature sets.
> 
> See http://www.imc.org/ietf-medfree

Thanks for the reference. Interesting work.

--
Chris

From: "Larry Masinter" <[email-masked]>
To: "Bert Bos" <[email-masked]>, <[email-masked]>
Subject: RE: Media types for XSL stylesheets
Date: Tue, 12 Oct 1999 10:19:54 PDT
Importance: Normal
Sender: [email-masked]

> On the other hand, if you have a format that allows a wide, maybe even
> open-ended range of things to be embedded in it, such as a multipart
> MIME message, or the SCRIPT element of HTML, then you need a more
> flexible way to label the embedding. MIME types seem to do that very
> well, so both these formats have adopted them as the labeling
> mechanism.

Actually, there's an issue with HTML use of MIME to label SCRIPT
elements: no one has registered any MIME types for embedded script
languages. Although the HTML 4.0 document mentions "text/javascript",
"text/vbscript", "text/tcl" in examples, they're not registered.
My guess is that the registration would push back and suggest
registering them as "application" and possibly as faceted
"application/vnd.ms-vbscript", "application/vnd.tcl".

> That leads to another issue: MIME type are not only used to get the
> interpretation started, but also to negotiate capabilities between a
> client and a server, e.g., in HTTP. In that context, sending a
> document with embedded XSL to a client that has indicated not being
> able to handle XSL is not very smart.

MIME types aren't used effectively for HTTP negotiation; the use
of "Accept" headers has proven unwieldy. We're still looking for
some other kind of capability/profile mechanism that would be suitable.
The CONNEG work and the continuing CCPP work in W3C will hopefully
yield a workable mechanism.

> In other words, that document with its embedded XSL needs not just a
> MIME type for its first byte, but also a description (a "profile") of
> the other capabilities a client needs. That would be something like a
> CC/PP( http://www.w3.org/Mobile/CCPP/ ) profile, I assume, and inside
> that there *would* be an entry that says "application/xsl" (or whatever
> the MIME type will be).

It isn't necessary to have a MIME type to talk about a capability.
That is, you could have a feature which is "able to interpret XSL style"
without registering "application/xsl".

The recognition that MIME labelling is insufficient for fine-grained
description of recipient capabilities or document profiles was the
foundation of the CONNEG work; it seems likely that CCPP can use the
CONNEG registry and a superset of the semantics of CONNEG feature
sets, although likely with an XML (RDF?) based syntax for feature sets.

See http://www.imc.org/ietf-medfree

> 
> 
> Bert
> -- 
>   Bert Bos                                ( W 3 C ) http://www.w3.org/
>   http://www.w3.org/people/bos/                              W3C/INRIA
>   [email-masked]                             2004 Rt des Lucioles / BP 93
>   +33 (0)4 92 38 76 92            06902 Sophia Antipolis Cedex, France
> 
> 

Date: Tue, 12 Oct 1999 19:01:14 +0200
From: Chris Lilley <[email-masked]>
To: MURATA Makoto <[email-masked]>
CC: [email-masked], [email-masked]
Subject: Re: Media types for XSL stylesheets
Sender: [email-masked]

MURATA Makoto wrote:

> 3) An XSL stylesheet may be embedded as a part of XML document itself and
> is referenced by a fragment identifier from this XML document.  The above
> example demonstrates such an embedded XSL stylesheet.

Yes

> 5) The example quoted above is controvertial.  If this document is delivered
> as "text/xml", what will be the media type for the referenced (embedded)
> XSL stylesheet?  text/xml or text/xsl?

It is not a separate resource and thus, the stylesheet portion does not
have or need a separate media type, would be my explanation. There is no
message body or separate bodypart to label.

The media type for the document as a whole would be that of the root
element; either a specialised type, if it has one, or a more generic
application/xml, as appropriate.

--
Chris

From: Bert Bos <[email-masked]>
Date: Tue, 12 Oct 1999 16:59:38 +0200 (MET DST)
To: [email-masked]
Subject: Re: Media types for XSL stylesheets
Sender: [email-masked]

John Cowan writes:
> MURATA Makoto scripsit:
> 
> > I think that such an embedded portion INHERITS the media type of the 
> > document.  Even if a stylesheet linking PI specifies a different media type, 
> > it is merely ignored.
> 
> Not necessarily.  A portion of image/gif is by no means an image/gif.
> Media types exist so that uninterpreted bytes get an interpretation,
> but internal resources have already been interpreted.

The GIF format indeed defines a set of chunk codes, so embeddings in
GIF are implicitly typed by the GIF spec and do not need MIME.

On the other hand, if you have a format that allows a wide, maybe even
open-ended range of things to be embedded in it, such as a multipart
MIME message, or the SCRIPT element of HTML, then you need a more
flexible way to label the embedding. MIME types seem to do that very
well, so both these formats have adopted them as the labeling
mechanism.

That leads to another issue: MIME type are not only used to get the
interpretation started, but also to negotiate capabilities between a
client and a server, e.g., in HTTP. In that context, sending a
document with embedded XSL to a client that has indicated not being
able to handle XSL is not very smart.

In other words, that document with its embedded XSL needs not just a
MIME type for its first byte, but also a description (a "profile") of
the other capabilities a client needs. That would be something like a
CC/PP[1] profile, I assume, and inside that there *would* be an entry
that says "application/xsl" (or whatever the MIME type will be).

[1] http://www.w3.org/Mobile/CCPP/

Bert
-- 
  Bert Bos                                ( W 3 C ) http://www.w3.org/
  http://www.w3.org/people/bos/                              W3C/INRIA
  [email-masked]                             2004 Rt des Lucioles / BP 93
  +33 (0)4 92 38 76 92            06902 Sophia Antipolis Cedex, France

Date: Tue, 12 Oct 1999 10:41:32 -0400
To: [email-masked]
From: "Simon St.Laurent" <[email-masked]>
Subject: Re: Media types for XSL stylesheets
Sender: [email-masked]

At 10:47 AM 10/12/99 -0400, John Cowan wrote:
>MURATA Makoto scripsit:
>
>> I think that such an embedded portion INHERITS the media type of the 
>> document.  Even if a stylesheet linking PI specifies a different media
type, 
>> it is merely ignored.
>
>Not necessarily.  A portion of image/gif is by no means an image/gif.
>Media types exist so that uninterpreted bytes get an interpretation,
>but internal resources have already been interpreted.

I guess I'd like to ask at this point whether XML-based media types are
sufficiently different from other media types that this interpretation is
no longer necessarily _mandatory_.

In large part, the interests I have in XML revolve around the fact that any
well-formed portion of an XML document is itself an XML document, and that
distinction between 'internal' and 'external' resources no longer matters
nearly as strongly.

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

From: John Cowan <[email-masked]>
Subject: Re: Media types for XSL stylesheets
To: [email-masked] (MURATA Makoto)
Date: Tue, 12 Oct 1999 10:47:01 -0400 (EDT)
Cc: [email-masked], [email-masked]
Sender: [email-masked]

MURATA Makoto scripsit:

> I think that such an embedded portion INHERITS the media type of the 
> document.  Even if a stylesheet linking PI specifies a different media type, 
> it is merely ignored.

Not necessarily.  A portion of image/gif is by no means an image/gif.
Media types exist so that uninterpreted bytes get an interpretation,
but internal resources have already been interpreted.

-- 
John Cowan                                   [email-masked]
       I am a member of a civilization. --David Brin

From: MURATA Makoto <[email-masked]>
Date: Tue, 12 Oct 1999 22:42:48 +0900
To: John Cowan <[email-masked]>
Cc: [email-masked], [email-masked]
Subject: Re: Media types for XSL stylesheets
Sender: [email-masked]

John Cowan wrote:
> There is no reason why an embedded portion of a document should have a
> media type.  The document's overall media type might be text/xml,
> application/xml, or anything else; the fact that it contains an
> embedded XSL instance is irrelevant.

I think that such an embedded portion INHERITS the media type of the 
document.  Even if a stylesheet linking PI specifies a different media type, 
it is merely ignored.

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

From: John Cowan <[email-masked]>
Subject: Re: Media types for XSL stylesheets
To: [email-masked] (MURATA Makoto)
Date: Tue, 12 Oct 1999 10:01:45 -0400 (EDT)
Cc: [email-masked], [email-masked]
Sender: [email-masked]

MURATA Makoto scripsit:

> 5) The example quoted above is controvertial.  If this document is delivered 
> as "text/xml", what will be the media type for the referenced (embedded) 
> XSL stylesheet?  text/xml or text/xsl?

There is no reason why an embedded portion of a document should have a
media type.  The document's overall media type might be text/xml,
application/xml, or anything else; the fact that it contains an
embedded XSL instance is irrelevant.

-- 
John Cowan                                   [email-masked]
       I am a member of a civilization. --David Brin

From: MURATA Makoto <[email-masked]>
Date: Tue, 12 Oct 1999 18:01:48 +0900
To: James Clark <[email-masked]>
Cc: [email-masked]
Subject: Re: Media types for XSL stylesheets
Sender: [email-masked]

James Clark wrote:
> MURATA Makoto wrote:
> 
> > I would suggest application/xsl-xml (other than application/xml).
> 
> Why application/xsl-xml rather than application/xslt-xml? Wouldn't
> application/xsl-xml would suggest it was limited to XSL stylesheets
> (i.e. XSLT stylesheets that generate XSL FOs)? What's needed is
> something that works for any XSLT stylesheet.

I agree that xslt-xml is better.

> > It might be a
> > good idea to follow the "*/*-xml" contention,
> 
> What exactly is the current status of this convention?  Has this
> convention become the official policy of the media types registry?  If
> not, when is it expected to become the official policy?

Since the current draft is merely an I-D, there is no "official policy".  
However, there appear to be no strong opposition in this mailing list.  By 
reading the discussion in the past, I have a feeling that some people love 
the convention and others can live with it.  (If somebody cannot live with it, 
speak up now!)

There have been some other proposals such as the top-level media type "xml", 
hierarchical media types, another convention "*/xml-*", and an added 
parameter for text/xml and application/xml.  Some people have strongly 
disagreed with these proposals.  (More about this, see the archive of this 
mailing list at http://www.imc.org/ietf-xml-mime/mail-archive)

Since we do not lose anything by chosing application/xslt-xml rather 
than application/xslt, I think that we should try application/xslt-xml. 

Cheers,

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

Date: Tue, 12 Oct 1999 15:31:10 +0700
From: James Clark <[email-masked]>
To: MURATA Makoto <[email-masked]>
CC: [email-masked]
Subject: Re: Media types for XSL stylesheets
Sender: [email-masked]

MURATA Makoto wrote:

> I would suggest application/xsl-xml (other than application/xml).

Why application/xsl-xml rather than application/xslt-xml? Wouldn't
application/xsl-xml would suggest it was limited to XSL stylesheets
(i.e. XSLT stylesheets that generate XSL FOs)? What's needed is
something that works for any XSLT stylesheet.

> Since XSL stylesheets are not readable for casual readers, text/* is not
> appropriate  (see the criteria explained by Ned Freed [1]).

I'm not sure I would agree that all XSLT stylesheets are not readable by
casual readers.
However, there are certainly plenty of XSLT stylesheets that aren't
suitable for casual readers, and I think having both a text/* and an
application/* registration is an unnecessary complication, so I would be
happy with application/*.

> It might be a
> good idea to follow the "*/*-xml" contention,

What exactly is the current status of this convention?  Has this
convention become the official policy of the media types registry?  If
not, when is it expected to become the official policy?

James

From: MURATA Makoto <[email-masked]>
Date: Tue, 12 Oct 1999 16:05:37 +0900
To: James Clark <[email-masked]>
Cc: [email-masked]
Subject: Re: Media types for XSL stylesheets
Sender: [email-masked]

James Clark wrote:
> 
> > Do you intend to introduce XSLT-specific fragment identifiers in the
> > future?
> 
> I don't know of any plans to do this.
> 
> > Or, do you intend to use XPointer for referencing into XSLT?
> 
> That's what I would expect.

Then, I would suggest application/xsl-xml (other than application/xml).  
Since XSL stylesheets are not readable for casual readers, text/* is not 
appropriate  (see the criteria explained by Ned Freed [1]).  It might be a 
good idea to follow the "*/*-xml" contention, since you do not want to lose 
the support of generic XML processing such as XPointer.  

I think that text/xml is not appropriate for XSLT since an XSLT stylesheet 
is not readable by casual users.

[1] http://www.imc.org/ietf-xml-mime/mail-archive/msg00203.html 

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

Date: Tue, 12 Oct 1999 12:40:16 +0700
From: James Clark <[email-masked]>
To: MURATA Makoto <[email-masked]>
CC: [email-masked]
Subject: Re: Media types for XSL stylesheets
Sender: [email-masked]

MURATA Makoto wrote:
> 
> James Clark wrote:
> > I suspect a specialized media type for XSLT is needed, since
> 
> Let me ask a question about fragment identifiers
> 
> Do you intend to introduce XSLT-specific fragment identifiers in the
> future?

I don't know of any plans to do this.

>  For example, "return the first template rule which has the pattern text()"?
> Or, do you intend to use XPointer for referencing into XSLT?

That's what I would expect.

James

From: MURATA Makoto <[email-masked]>
Date: Tue, 12 Oct 1999 14:26:54 +0900
To: James Clark <[email-masked]>
Cc: [email-masked]
Subject: Re: Media types for XSL stylesheets
Sender: [email-masked]

James Clark wrote:
> I suspect a specialized media type for XSLT is needed, since

Let me ask a question about fragment identifiers

Do you intend to introduce XSLT-specific fragment identifiers in the 
future?  For example, "return the first template rule which has the pattern text()"?
Or, do you intend to use XPointer for referencing into XSLT?

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

Date: Tue, 12 Oct 1999 10:01:21 +0700
From: James Clark <[email-masked]>
To: [email-masked]
Subject: Re: Media types for XSL stylesheets
Sender: [email-masked]

MURATA Makoto wrote:

> I read your mail and the XSL PR.  I think that the PR has done a very good
> job, since it uses text/xml and application/xml and still keeps the door
> open for XSL-specialized media types.

I think eventually it would be desirable to have an XSL-specialized
media type and now seems like a good time to start a discussion of this.

First, a bit more background to supplement what you have already given.

1. There are two specs involved here, XSLT and XSL.  XSLT, which has
just become a PR, is a language expressed in XML for transforming XML
documents.  XSL, which is currently a WD, defines an XML language for
specifying formatting (at a semantic level similar to RTF rather than
PDF); this language is usually called XSL FO (Formatting Objects).  An
XSL stylesheet is an XSLT stylesheet that transforms into XSL FOs. XSL
is thus the combination of XSLT and XSL FO. XSL FO is not a separate
spec.

2. XSLT is not restricted to transform into XML.  Although it always
conceptually produces an XML tree, than XML tree need not be serialized
as XML.  It can be serialized as HTML or as plain text.  XSLT allows
stylesheets to declare the media type of the result.  You can have XSLT
stylesheets that transform into VRML or SVG.  A browser could launch the
appropriate viewer based on the declared result media type.

3. XSL FOs can potentially be mixed with other XML vocabularies such as
SVG.

I suspect a specialized media type for XSLT is needed, since

- it's not always possible to tell that an XML document is an XSLT
stylesheet; for example,

  <doc/>

is a legal XSLT stylesheet (whose semantics are to transform any XSLT
document to an XML document containing just a single empty "doc"
element); thus even if there was a way with application/xml to indicate
the namespace URIs used, this would not be enough for content
negotiation to work

- it would be useful for the media type for XSLT to have a parameter
that declared the media type of the result of a transformation; in order
for a browser to be able to use an XSLT stylesheet to display a
document, it needs not just to be able to handle XSLT but also to be
able to handle the result of the XSLT process; this seems specific to
XSLT

I don't think there needs to be a specific media type for XSL. XSL
should be handled as an instance of the XSLT media type.  

I'm not sure about XSL FOs. One way to deal with them would be as an
instance of application/xml with a parameter indicating the namespace
URIs used, but that would make the media type of an XSL stylesheet
something like

application/xslt; result="application/xml;
namespace-uris=\"http://www.w3.org/1999/XSL/Format\""

which is a bit unwieldy.

James

From: MURATA Makoto <[email-masked]>
Date: Tue, 12 Oct 1999 11:14:13 +0900
To: James Clark <[email-masked]>
Cc: [email-masked]
Subject: Re: Media types for XSL stylesheets
Sender: [email-masked]

James Clark wrote:
> You must be looking at an old WD.

I am afraid that I made a mistake.  I tried the http://www.w3.org/TR/xslt, 
but the server returned an old file in the cash.  My apologies.

I read your mail and the XSL PR.  I think that the PR has done a very good 
job, since it uses text/xml and application/xml and still keeps the door 
open for XSL-specialized media types.

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

Date: Tue, 12 Oct 1999 08:59:05 +0700
From: James Clark <[email-masked]>
To: MURATA Makoto <[email-masked]>
CC: [email-masked]
Subject: Re: Media types for XSL stylesheets
Sender: [email-masked]

You must be looking at an old WD.

The PR says: "The MIME media types text/xml and application/xml
[RFC2376] should be used for XSLT stylesheets. It is possible that a
media type will be registered specifically for XSLT stylesheets; if and
when it is, that media type may also be used."

The example in 2.7 uses text/xml.

2.3 also warns that: "In some situations, the only way that a system can
recognize that an XML document needs to be processed by an XSLT
processor as an XSLT stylesheet is by examining the XML document itself.
Using the simplified syntax makes this harder, and can even make it
impossible if the xsl:version attribute is omitted from the document
element. Therefore, the simplified syntax should not be used for XSLT
stylesheets that may be used in such a situation. This situation can,
for example, arise when an XSLT stylesheet is transmitted as a message
with a MIME media type of text/xml or application/xml to a recipient
that will use the MIME media type to determine how the message is
processed."

MURATA Makoto wrote:
> 
> XSL Transformations (XSLT) has become a proposed recommendation of W3C.
> The URL is:
>         http://www.w3.org/TR/xslt
> 
> An example in 2.7 "Embedding Stylesheets" uses "text/xsl".
> 
>         <?xml-stylesheet type="text/xsl" href="#style1"?>
>         <!DOCTYPE doc SYSTEM "doc.dtd">
>         <doc>
>         <head>
>         <xsl:stylesheet id="style1"
>                 xmlns:xsl="http://www.w3.org/XSL/Transform/1.0"
>                 xmlns:fo="http://www.w3.org/XSL/Format/1.0">
>         <xsl:import href="doc.xsl"/>
>         <xsl:template match="id('foo')">
>           <fo:block font-weight="bold"><xsl:apply-templates/></fo:block>
>         </xsl:template>
>         <xsl:template match="xsl:stylesheet">
>           <!-- ignore -->
>         </xsl:template>
>         </xsl:stylesheet>
>         </head>
>         <body>
>         <para id="foo">
>         ...
>         </para>
>         </body>
>         </doc>
> 
> However, there is a note as below:
> 
>         NOTE: The text/xsl media type has not been registered. No decision
>         has been made on whether a media type other than text/xml or
>         application/xml will be used for XSLT and XSL.
> 
> Here is some background information about this issue.
> 
> 1) At present, AFAIK, XSL is the only stylesheet in the XML syntax.  But this
> may change at any time.
> 
> 2) An XSL stylesheet does not always begin with the XSL namespace.  If it
> is written in the simplified syntax shown in "2.3 Literal Result Element as
> Stylesheet" of XSLT, it can begin with any namespace.
> 
> 3) An XSL stylesheet may be embedded as a part of XML document itself and
> is referenced by a fragment identifier from this XML document.  The above
> example demonstrates such an embedded XSL stylesheet.
> 
> 4) The combination of 3) and 4) means that an embedded stylesheet may
> be in the simplified syntax, and can begin with any namespace.
> 
> 5) The example quoted above is controvertial.  If this document is delivered
> as "text/xml", what will be the media type for the referenced (embedded)
> XSL stylesheet?  text/xml or text/xsl?
> 
> Makoto
> 
> Fuji Xerox Information Systems
> 
> Tel: +81-44-812-7230   Fax: +81-44-812-7231
> E-mail: [email-masked]

From: MURATA Makoto <[email-masked]>
Date: Tue, 12 Oct 1999 10:28:53 +0900
To: [email-masked]
Cc: [email-masked]
Subject: Media types for XSL stylesheets
Sender: [email-masked]

XSL Transformations (XSLT) has become a proposed recommendation of W3C.  
The URL is:
	http://www.w3.org/TR/xslt

An example in 2.7 "Embedding Stylesheets" uses "text/xsl".

	<?xml-stylesheet type="text/xsl" href="#style1"?>
	<!DOCTYPE doc SYSTEM "doc.dtd">
	<doc>
	<head>
	<xsl:stylesheet id="style1"
                xmlns:xsl="http://www.w3.org/XSL/Transform/1.0"
                xmlns:fo="http://www.w3.org/XSL/Format/1.0">
	<xsl:import href="doc.xsl"/>
	<xsl:template match="id('foo')">
	  <fo:block font-weight="bold"><xsl:apply-templates/></fo:block>
	</xsl:template>
	<xsl:template match="xsl:stylesheet">
	  <!-- ignore -->
	</xsl:template>
	</xsl:stylesheet>
	</head>
	<body>
	<para id="foo">
	...
	</para>
	</body>
	</doc>

However, there is a note as below:

	NOTE: The text/xsl media type has not been registered. No decision 
	has been made on whether a media type other than text/xml or 
	application/xml will be used for XSLT and XSL.

Here is some background information about this issue.

1) At present, AFAIK, XSL is the only stylesheet in the XML syntax.  But this 
may change at any time.

2) An XSL stylesheet does not always begin with the XSL namespace.  If it 
is written in the simplified syntax shown in "2.3 Literal Result Element as 
Stylesheet" of XSLT, it can begin with any namespace.

3) An XSL stylesheet may be embedded as a part of XML document itself and 
is referenced by a fragment identifier from this XML document.  The above 
example demonstrates such an embedded XSL stylesheet.

4) The combination of 3) and 4) means that an embedded stylesheet may 
be in the simplified syntax, and can begin with any namespace. 

5) The example quoted above is controvertial.  If this document is delivered 
as "text/xml", what will be the media type for the referenced (embedded) 
XSL stylesheet?  text/xml or text/xsl?

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

Date: Sun, 10 Oct 1999 21:37:44 +0200
From: Chris Lilley <[email-masked]>
To: [email-masked]
CC: "'Simon St.Laurent'" <[email-masked]>, [email-masked]
Subject: Re: Announcement of an I-D
Sender: [email-masked]

Gavin Thomas Nicol wrote:
> 
> > So you expect software written for both SVG-specific and
> > XML-generic to understand both SVG and XML fragment identifier rules? 

No ;-)

> > It seems more
> > likely that SVG applications would only understand SVG FI
> > rules and XML applications would understand XPointer - fortunately, a
> > superset of SVG.

Yes.

> I think the question here is one of intent. If people believe that
> generic XML processors are going to be manipulating SVG as part of
> common practise, then it makes little sense to have a media-types
> specific fragment identifier. If SVG is *not* commonly going to be
> manipulated by generic XML processors, then a media-specific fragment
> id makes perfect sense. It's event better if they line up.

They do indeed line up, and sometimes SVG will be manipulated by generic
XML processors, and sometimes (often) it will be displayed by
SVG-specific processors.

--
Chris

Date: Sun, 10 Oct 1999 21:22:19 +0200
From: Chris Lilley <[email-masked]>
To: "Simon St.Laurent" <[email-masked]>
CC: [email-masked]
Subject: Re: Announcement of an I-D
Sender: [email-masked]

"Simon St.Laurent" wrote:
> 
> At 06:40 PM 9/29/99 +0200, Chris Lilley wrote:
> >"Simon St.Laurent" wrote:
> >> All suggestions regarding the fragment identifier issue are welcome.  My
> >> personal take is that non-SVG XML could (and in fact would probably have
> >> to) use conventional XPointers to reference _into_ SVG documents, making
> >> the -xml suffix important for identification.  This would not, however,
> >> constrain SVG documents from using their own fragment identifiers to
> >> reference other SVG documents.
> >
> >Hmm. I think you have that backwards. It is not where the reference
> >comes *from* that is important, but what it points *into*. Because the
> >fragment goes onto the end of a url.
> 
> I think we've got a fundamental disconnect here. 

Yes.

> Generic XML software (say
> a directory system or something making a reference) isn't going to care
> whether a given XML document is SVG or CGM or whatever.  All it necessarily
> knows is that the target document is XML.  Why should it know anything
> about SVG or CGM's fragment identifiers?

Because CGM is not written in XML, for starters. So an XPath/XPointer is
going to get you nowhere. CGM does have its own fragment identifier
syntax, and so that is what you use if you are pointing intoa CGM.
Similarly, if some video format had a fragment syntax thatlet you point
to a particular SMPTE timecode inside the movie, you would use that
media type's fragment syntax when pointing into that movie.

> The 'end of the URL' may not be processed by an application that
> understands SVG at all.  Is there some reason that it should?

Lets clarify here. By "end of the url" I meant the client side
specialiser, the part after the #.

So, in the case of a URL which points at an SVG file, then yes, it will
be an SVG application that processes it. The entire resource is returned
to the requesting application. Similarly, a URL pointing to HTML which
has a fragment identifier, will be processed by something that knows how
to deal with HTML fragment identifiers. And a URL pointingto a video
will have the fragment identifier processed by that video client.

These URLs could have been embeeded in an XML file, a CGM, a PDF, a
hotlist, or written on a napkin or typed on a command line. It doesn't
matter where they came from; its where they point to.

> 
> >Consider for example an xml file which contained a link to the third
> >picture in a CGM file. The URL would be that of the CGM, and the
> >fragment syntax used would be the WebCGM fragment syntax, not Xpointer.
> >Conversely, A WebCGM which contained a link into the third paragraph of
> >an XML file would use XPointer as the fragment identifier on the end of
> >the URL that pointed to the XML document.
> 
> So you expect software written for both SVG-specific and XML-generic to
> understand both SVG and XML fragment identifier rules? 

No. (And its a pity you moved the example, because my example was
clearer, since CGM is not writen in XML). It sounds as if you are
confusing the roles of link recognition (which is dealt with by the
place where the link starts from) and fragment resolution, which happens
when the requested resource has been retrieved and dispatched to the
appropriate handler.

> It seems more
> likely that SVG applications would only understand SVG FI rules and XML
> applications would understand XPointer

Yes! Which is what I said, and thus, the thing that knows how to
interpret the fragment identifier is in charge of dealing with it once
the resource has been fetched.

- fortunately, a superset of SVG.

Yes, which is why SVG does not make a very clear example in these
discussions, which is why I picked something (WebCGM) which is not
written in XML and which already has its own defined fragment syntax.

> If you want to operate this way, why have different fragment identifier
> rules at all?  It seems like you've just created extra work for all kinds
> of applications.

No, not at all. I think, as you yourself said when you started this
message, that you have misunderstood me. I don't think we disagree at
all, in fact.

--
Chris

From: MURATA Makoto <[email-masked]>
Date: Fri, 08 Oct 1999 21:16:15 +0900
To: [email-masked]
Subject: Re: Announcement of an I-D
Sender: [email-masked]

Chris Lilley wrote:
> 
> 
> MURATA Makoto wrote:
> > Q1.  If you introduce a media type "image/svg",  you can certainly introduce
> > SVG-specific fragment
> > identifiers. 
> 
> There are two issues here.
> 
> Firstly, since it is defining a media type, it needs to define what the
> fragment identifier syntax is. We use XPointer, but in this release
> restict it to pointing to IDs. This is because we want a spec that is
> fully implemented very rapidly.
> 
> Later versions will probably remove this restriction, once XLink and
> XPointer are more established.

16.2.2 "SVG fragment identifiers" of the latest draft of SVG [1] introduces 
SVG view specifications such as "MyDrawing.svg#svgView(viewBox(0,200,1000,1000)))". 

>16.2.2. SVG fragment identifiers
>
> Shorthand bare name form of addressing (e.g.,
> MyDrawing.svg#MyView). This form of addressing, which 
> allows addressing an SVG element by its ID, is compatible 
> with the fragment addressing mechanism for older versions of 
> HTML and the shorthand bare name formulation in "XML Pointer 
> Language (XPointer)" [XPTR]. (The bare name form of addressing 
> #MyElement is equivalent to the XPointer formulation 
> #xptr(id('MyView')).)
> 
> XPointer-compatible ID reference (e.g.,
> MyDrawing.svg#xptr(id('MyView'))). This form of addressing, 
> which also allows addressing an SVG element by its ID, is 
> compatible with the syntax for referencing IDs in "XML Pointer 
> Language (XPointer)" [XPTR].
> 
> SVG view specification (e.g.,
> MyDrawing.svg#svgView(viewBox(0,200,1000,1000))). This form of
> addressing specifies the desired view of the document (e.g., 
> the region of the document to view, the initial zoom level) 
> completely within the SVG fragment specification. The contents 
> of the SVG view specification are the five parameter specifications, 
> viewBox(...), preserveAspectRatio(...), transform(...), 
> allowZoomAndPan(...) and viewTarget(...), whose parameters have 
> the same meaning as the corresponding attributes on a <view> element.
> 

Chris Lilley wrote:
> 
> I would like to understand what you mean by "SVG fragment identifier"
> before being able to answer how I feel. I need to understand your
> question better first.

Let me reformulate my question.  Suppose that I have an XHTML document.  
The first subsection of the second section has an embedded SVG.  

I would like to use an XPointer to specify "the SVG in the first subsection 
of the second section".  Then, I would like to obtain a region of this SVG 
by using an SVG view specficiation such as svgView(viewBox(0,200,1000,1000))).

I would like to combine the XPointer and the SVG view specfication to form a 
fragment identifier.  I think I cannot do this, since SVG view speficiations 
require image/svg and XPointer requires text/xml or application/xml (or */*-xml).  
Am I right?

#Probably, I am repeating the debate Gavin did long time ago.

[1] http://www.w3.org/TR/SVG/linking.html#LinksIntoSVG

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

From: MURATA Makoto <[email-masked]>
Date: Fri, 08 Oct 1999 21:03:18 +0900
To: [email-masked]
Subject: Re: Announcement of an I-D
Sender: [email-masked]

Chris Lilley wrote:
>  
> "Simon St.Laurent" wrote:
> > I don't think xml- is introduced as a general convention for anything.
> > xml-dtd can be the form for XML DTD information in large part because DTD
> > files are not themselves well-formed XML documents.
> 
> Agreed. Could the same type be used for other "parts of xml" which are
> not by themselves well-formed xml documents? I am thinking of external
> parsed entities.

Which media type should we use for external parsed entities?  This is an 
interesting exercise.  There are two cases.  

Case 1: an external parsed entity is also a standalone XML document.  

For example, 

<?xml version="1.0" encoding="utf-8"?>
<dmy/>

is a standalone XML document, but can be referenced as an external 
parsed entity.  For example, 

<?xml version="1.0"?>
<!DOCTYPE test [
<!ELEMENT test (#PCDATA|dmy)*>
<!ELEMENT dmy EMPTY>
<!ENTITY ent SYSTEM "./url-for-the-parsed-entity">
]>
<test>&ent;</test>

For such external parsed entities, text/xml or application/xml works perfectly 
well. 

Case 2: An external parsed entity is not a standalone XML document.

There are two subcases.  The first subcase is that the client side is expecting 
an external parsed entity.  The second subcase is that the client side has 
no information in advance.

Subcase 1:

The client needs the charset parameter only.  The media type is not useful, 
since the client already knows that the MIME entity is an XML parsed entity.  
Thus, text/xml or application/xml works.

Subcase 2:

If the media type is text/xml or application/xml, the MIME client would probably 
invoke an XML processor, and get a fatal error.  Is this a problem?  I think 
that it is OK.  After all, the client cannot do anything useful, since 
the external parsed entity does not parse as an XML document.

Cheers,

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

Reply-To: <[email-masked]>
From: "Gavin Thomas Nicol" <[email-masked]>
To: "'Simon St.Laurent'" <[email-masked]>, "'Chris Lilley'" <[email-masked]>
Cc: <[email-masked]>
Subject: RE: Announcement of an I-D
Date: Sun, 3 Oct 1999 04:18:56 -0400
Importance: Normal
Sender: [email-masked]

> So you expect software written for both SVG-specific and
> XML-generic to understand both SVG and XML fragment identifier rules?  It
seems more
> likely that SVG applications would only understand SVG FI
> rules and XML applications would understand XPointer - fortunately, a
> superset of SVG.

I think the question here is one of intent. If people believe that
generic XML processors are going to be manipulating SVG as part of
common practise, then it makes little sense to have a media-types
specific fragment identifier. If SVG is *not* commonly going to be
manipulated by generic XML processors, then a media-specific fragment
id makes perfect sense. It's event better if they line up.

I remember getting into this debate years ago when I proposed having
a generic tree-structured fragment identifier for *all* media types
(non-herarchical data could be handled with just single-level
qualification). You can see where the debate ended up...

Date: Fri, 01 Oct 1999 12:43:40 -0400
To: Chris Lilley <[email-masked]>
From: "Simon St.Laurent" <[email-masked]>
Subject: Re: Announcement of an I-D
Cc: [email-masked]
Sender: [email-masked]

At 06:40 PM 9/29/99 +0200, Chris Lilley wrote:
>"Simon St.Laurent" wrote: 
>> All suggestions regarding the fragment identifier issue are welcome.  My
>> personal take is that non-SVG XML could (and in fact would probably have
>> to) use conventional XPointers to reference _into_ SVG documents, making
>> the -xml suffix important for identification.  This would not, however,
>> constrain SVG documents from using their own fragment identifiers to
>> reference other SVG documents.
>
>Hmm. I think you have that backwards. It is not where the reference
>comes *from* that is important, but what it points *into*. Because the
>fragment goes onto the end of a url.

I think we've got a fundamental disconnect here.  Generic XML software (say
a directory system or something making a reference) isn't going to care
whether a given XML document is SVG or CGM or whatever.  All it necessarily
knows is that the target document is XML.  Why should it know anything
about SVG or CGM's fragment identifiers?

The 'end of the URL' may not be processed by an application that
understands SVG at all.  Is there some reason that it should?

>Consider for example an xml file which contained a link to the third
>picture in a CGM file. The URL would be that of the CGM, and the
>fragment syntax used would be the WebCGM fragment syntax, not Xpointer.
>Conversely, A WebCGM which contained a link into the third paragraph of
>an XML file would use XPointer as the fragment identifier on the end of
>the URL that pointed to the XML document.

So you expect software written for both SVG-specific and XML-generic to
understand both SVG and XML fragment identifier rules?  It seems more
likely that SVG applications would only understand SVG FI rules and XML
applications would understand XPointer - fortunately, a superset of SVG.

If you want to operate this way, why have different fragment identifier
rules at all?  It seems like you've just created extra work for all kinds
of applications.

Simon St.Laurent
XML: A Primer (2nd Ed - September)
Building XML Applications
Inside XML DTDs: Scientific and Technical
Sharing Bandwidth / Cookies
http://www.simonstl.com