[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
Subject: Re: Which file should be the basis for pointing into XSLT?
At 31 Aug 2000 07:21 -0400, G. Ken Holman wrote: > Hi everyone! Hi Ken! ... > Should I base the navigation of the XSLT specification on the XML source > file or on the HTML rendition? I'm speaking here of when one of our tests > references one of the normative locations of the XSLT Recommendation, where > should it point? Base the navigation on the XML sources of the Recommendations. A version of the HTML with sufficient anchors for us to individually locate every significant phrase in the Recommendations doesn't currently exist, so we (or you) are going to have to create it. > I am of two minds: > > (1) I figured the XML source of the XSLT specification is normative and the > HTML rendition is just that, a rendition of the normative document, so we > could be referencing the normative document and users of the suite could > then navigate into the source document (but what would they use for browsing?) > > (2) I also figured the HTML rendition of the XSLT specification is what > most (all?) users of our test suite will be using, hence the pointers could > be relative to an XHTML version of the rendition document ... but would > there ever be other renditions? > > I can modify the DSSSL scripts to go either way, I'm just not sure what the > committee thinks should be done. > > Looking in Tony's document, he is basing his pointers on the XML source of > the recommendation ... > > "An element from the XSLT namespace may have any attribute..." > > XML Source: /spec[1]/body[1]/div1[2]/div2[1]/p[4] > > But the document people will be navigating will be the HTML document ... > the corresponding XPointer really isn't very useful, but could be what I > base my indexing on: > > HTML Output: /html[1]/body[1]/p[26] > > I think that perhaps what we do is document the XML XPointer but use the > HTML XPointer for jumping into a modified version of the HTML rendition > with anchors for every text node. I'll work out a way to synchronize the two. But what current software understands HTML XPointers? When you put anchors in the HTML, base them on the XPointer of the corresponding element or span of text in the XML source, so that once you have the XPointer for the location in the XML source, you can create a link to the corresponding location in the HTML. An alternative is for us to ID every significant element and every significant span of text -- since we do need a way to associate individual tests with their relevant text in the Recommendations -- and use those IDs as anchors in the HTML version. IDs rather than either XPointers or IDs that are XPointers in disguise would be more robust across versions of the specs. Ideally, I'd like to have data in the form of ID-XPointer pairs, the XML for a Recommendation, and an XSLT stylesheet that reads the data and the Recommendation and then produces an HTML version with anchors in place for every significant span of text specified in the data. If the users have an HTTP-savvy XSLT processor, they should be able to run the stylesheet on the Recommendation's XML that is on the W3C's web site. The generated HTML can be referred to from other parts of the test suite's documentation, plus it should be possible to get from a span of text in the HTML to the tests that test for the specific behaviour defined by that span of text. Regards, Tony Graham ====================================================================== Tony Graham mailto:tgraham@mulberrytech.com Mulberry Technologies, Inc. http://www.mulberrytech.com 17 West Jefferson Street Direct Phone: 301/315-9632 Suite 207 Phone: 301/315-9631 Rockville, MD 20850 Fax: 301/315-8285 ---------------------------------------------------------------------- Mulberry Technologies: A Consultancy Specializing in SGML and XML ======================================================================
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
Powered by eList eXpress LLC