- From: David Carlisle <davidc@nag.co.uk>
- Date: Mon, 22 Nov 2004 16:55:00 GMT
- To: www-tag@w3.org
Jonathan Borden I don't think there is much of any official w3c work on preserving IDs across transforms, so short of some new research I can't see how you are going to be able to solve that issue. I doubt it's possible to say much in general about what an arbitrary transformation language like xslt does or does not do about ids (or any other feature of the source) however it would be possible for the TAG to state whether current browsers are, or are not, doing the RightThing when they interpret http://www.w3.org/TR/MathML2/chapter1.xml#id.1.3.2 as a reference to section 1.3.2 of chapter 1 of the MathML spec, and scroll the display appropriately. As it happens chapter1.xml does have an element with id equal to id.1.3.2, however the browsers (IE and mozilla family) wouldn't care if it did not, so long as the referenced stylesheet generated an html element with that id (or an a element with that name) in the internal html representation. For example if instead of the XHTML we served the original xmlspec XML source, referencing the xmlspec stylesheet then the fragment id #id.1.3.2 would still work (as the browser would be rendering the same generated html) but the original source has no such id (it is generated by the stylesheet). This behaviour is clearly useful (and I make use of it all the time) and it would be a shame to say it "SHOULD NOT" occur, however I struggle to find any justification for it in the URI RFC's which would seem to imply that the #id.1.3.2 ought to refer to an identifier in a format governed by the mime type of http://www.w3.org/TR/MathML2/chapter1.xml (and so would be an error if the xml document didn't have an id of that name) David ________________________________________________________________________ This e-mail has been scanned for all viruses by Star. The service is powered by MessageLabs. For more information on a proactive anti-virus service working around the clock, around the globe, visit: http://www.star.net.uk ________________________________________________________________________
Received on Monday, 22 November 2004 16:55:45 UTC