Re: 3023 update (was Re: Agenda TAG Telcon: 8th Nov 2004)

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