"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