Subject: Re: Announcement of an I-D
From: Chris Lilley <[email-masked]>
To: MURATA Makoto <[email-masked]>
Cc: [email-masked]
Date: Thu, 30 Sep 1999 17:44:26 +0200

MURATA Makoto wrote:
> 
> Chris,
> 
> I think that this is a very interesting issue.  Let me ask some questions.
> 
> 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.

Secondly, since XPointer wisely moved toa prefixed syntax, ie xptr(), it
becomes possible to define other syntaxes. For example, a means of
linking to particular time periods, or a way of linking to particular
geometric regions, and so on. Thisis sonmething that SVG might be
intereste din later, but we have not done this for SVG 1.0

> But are you willing to give up referencing into SVG embedded
> into XHTML?

I don't see how I am giving this up. Such a file would not be served up
as image/svg (or indeed as image/svg-xml) - it would be served up as
application/xml, or application/xhtml-xml, or something else.

> Q2.  How do you feel about making fragment identifiers namespace -sensitive?
> For example, "if the
> root element is of the namespace for SVG, the fragment identifier is
> interpreted as ...."

That might be possible, but at the moment they are dependent on the
media type only.

> Q3.  If we really want to make fragment identifiers namespace- sensitive, we
> can even interpret
> different portions of a single fragment identifier differently.  For
> example, the first two conditions
> are interpreted as XPath and the third condition is interpreted as SVG
> fragment identifier, and

You seem to be under the impresion that SVG has some special fragment
syntax. It has a proper subset of XPointer.

> the forth condition is intepreted as XPath (i.e., references into XHTML
> embedded in the SVG).
> How do you feel?

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.

--
Chris

Reply-To: "MURATA Makoto" <[email-masked]>
From: "MURATA Makoto" <[email-masked]>
To: <[email-masked]>
Subject: RE: Announcement of an I-D
Date: Thu, 30 Sep 1999 23:48:03 +0900
Sender: [email-masked]

Chris,

I think that this is a very interesting issue.  Let me ask some questions.

Q1.  If you introduce a media type "image/svg",  you can certainly introduce
SVG-specific fragment
identifiers.  But are you willing to give up referencing into SVG embedded
into XHTML?

Q2.  How do you feel about making fragment identifiers namespace -sensitive?
For example, "if the
root element is of the namespace for SVG, the fragment identifier is
interpreted as ...."

Q3.  If we really want to make fragment identifiers namespace- sensitive, we
can even interpret
different portions of a single fragment identifier differently.  For
example, the first two conditions
are interpreted as XPath and the third condition is interpreted as SVG
fragment identifier, and
the forth condition is intepreted as XPath (i.e., references into XHTML
embedded in the SVG).
How do you feel?

Q3 might be a crazy idea.  But we have to consider non-monolithic XML
seriously, since it is
so common.

Cheers,

-----Original Message-----

>> Although we
>> do not actually believe this I-D is the right place for these media
types, we strongly
>> believe that we need some consistent story for XML-based languages of
W3C.
>
>I agree.
>
>The SVG WG (of which I am chair) plans to submit an Internet Media Type
>registration for SVG once that specification is stable (ie, W3C
>Recommendation).
>
>--
>Chris
>

Date: Wed, 29 Sep 1999 18:40:50 +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 01:46 PM 9/29/99 +0200, Chris Lilley wrote:
> > I need to read this ID closely to see what an
> >implementation might be expected to infer (or not) on getting a
> >foo/bar-xml-baz mimetype. Is this written in XML or not?
> 
> 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.

> According to this draft, foo/bar-xml-baz should _not_ be XML, and neither
> should foo/xml-bar-baz.  foo/bar-baz-xml should be XML.

OK, so it has to be the terminal part of the name. Good.

> >OK, will check exactly what promises image/svg-xml makes (in particular
> >regarding XPointer as a fragment identifier)
> 
> 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.

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.

--
Chris

Date: Wed, 29 Sep 1999 08:24:45 -0400
To: Chris Lilley <[email-masked]>, [email-masked]
From: "Simon St.Laurent" <[email-masked]>
Subject: Re: Announcement of an I-D
Cc: [email-masked]
Sender: [email-masked]

At 01:46 PM 9/29/99 +0200, Chris Lilley wrote:
>MURATA Makoto wrote:
>> 1. On top of text/xml and application/xml, this I-D further introduces
>> application/xml-dtd.
>> 
>> 2. The "*/*-xml" convention is introduced.  Throw a rock on it if you
disagree.
>
>OK, so both -xml and xml- are intrduced, with differeing meanings. This
>is fine, but I need to read this ID closely to see what an
>implementation might be expected to infer (or not) on getting a
>foo/bar-xml-baz mimetype. Is this written in XML or not?

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.

According to this draft, foo/bar-xml-baz should _not_ be XML, and neither
should foo/xml-bar-baz.  foo/bar-baz-xml should be XML.

>> 4. application/mathml-xml,application/xsl-xml, application/rdf-xml, and
image/svg-xml
>> are used as examples.  Concerned citizens are invited to send comments.  
>
>OK, will check exactly what promises image/svg-xml makes (in particular
>regarding XPointer as a fragment identifier)

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.

This is a critical point that needs more discussion from as many parties as
possible.

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

Date: Wed, 29 Sep 1999 13:46:43 +0200
From: Chris Lilley <[email-masked]>
To: MURATA Makoto <[email-masked]>
CC: [email-masked]
Subject: Re: Announcement of an I-D
Sender: [email-masked]

MURATA Makoto wrote:

> 1. On top of text/xml and application/xml, this I-D further introduces
> application/xml-dtd.
> 
> 2. The "*/*-xml" convention is introduced.  Throw a rock on it if you disagree.

OK, so both -xml and xml- are intrduced, with differeing meanings. This
is fine, but I need to read this ID closely to see what an
implementation might be expected to infer (or not) on getting a
foo/bar-xml-baz mimetype. Is this written in XML or not?

> 4. application/mathml-xml,application/xsl-xml, application/rdf-xml, and image/svg-xml
> are used as examples.  Concerned citizens are invited to send comments.  

OK, will check exactly what promises image/svg-xml makes (in particular
regarding XPointer as a fragment identifier)

> Although we
> do not actually believe this I-D is the right place for these media types, we strongly
> believe that we need some consistent story for XML-based languages of W3C.

I agree.

The SVG WG (of which I am chair) plans to submit an Internet Media Type
registration for SVG once that specification is stable (ie, W3C
Recommendation).

--
Chris

From: MURATA Makoto <[email-masked]>
Date: Mon, 27 Sep 1999 11:30:52 +0900
To: [email-masked]
Subject: Announcement of an I-D
Sender: [email-masked]

Simon St. Laurent and I co-authored an I-D for XML media types.  It 
is available at:

http://www.ietf.org/internet-drafts/draft-murata-xml-00.txt

This I-D is based on the discussion in this mailing list.  Major differences 
from RFC 2376 are as below:

1. On top of text/xml and application/xml, this I-D further introduces 
application/xml-dtd.

2. The "*/*-xml" convention is introduced.  Throw a rock on it if you disagree.

3. Some remaining issues are pointed out.

4. application/mathml-xml,application/xsl-xml, application/rdf-xml, and image/svg-xml 
are used as examples.  Concerned citizens are invited to send comments.  Although we 
do not actually believe this I-D is the right place for these media types, we strongly 
believe that we need some consistent story for XML-based languages of W3C.

FYI:  An I-D for text/html is avilable at:

http://www.ietf.org//internet-drafts/draft-connolly-text-html-00.txt

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