"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