[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Announcement of an I-D
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
XML: A Primer (2nd Ed - September)
Building XML Applications
Inside XML DTDs: Scientific and Technical
Sharing Bandwidth / Cookies