OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.


Help: OASIS Mailing Lists Help | MarkMail Help

xslt-conformance message

[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?

[Resending to the list after sending to only Ken earlier]

At 31 Aug 2000 19:54 -0400, G. Ken Holman wrote:
 > At 00/08/31 15:19 -0400, Tony Graham wrote:
 > But I was going to try and base the XPointers on IDs if possible instead of 
 > the root ... hopefully this will be more resilient to change.

They will be more resilient to change but not impervious.

If we, when working with the conformance tests, refer to the
significant portions of the Recommendations' text by IDs that we make
up, we can map from the IDs to the XPointers that locate the
significant portions of text in the Recommendations.  When the
Recommendations change, we can adjust the mapping of IDs to XPointers
to accommodate the change and not have to change every reference in
every test and every other piece of documentation in the test suite.

Of course the XPointers to the significant portions of text would make
the basis for a good first cut for the identifiers for the significant
portions of text.  When necessary, the identifiers could be changed
and all the test suite files updated by running a stylesheet on the
XML for the tests and the other documentation.  However, if, as I
recall from the Lotus test files, the identifiers are embedded in
comments in test files, updating those would be more problematic
because it would rely on test creators always writing structured
comments.  (Putting the identifiers in markup in the test files or
keeping the mapping of test files to Recommendation text outside the
test files would obviate this potential problem.)

 > >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.
 > Yes, I agree.
 > >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.
 > Well ... let's take a look at what happens when I do every text node and 
 > we'll see if that is sufficient granularity for our purposes.  After all, 
 > these are just to be guidelines for the reader of a given test.

Consider the following fragment from REC-xslt-19991116.xml:

   <p>When the first argument to the <function>document</function>
   function is not a node-set, the first argument is converted to a
   string as if by a call to the <xfunction>string</xfunction> function.
   This string is treated as a URI reference; the resource identified by
   the URI is retrieved. The data resulting from the retrieval action is
   parsed as an XML document and a tree is constructed in accordance with
   the data model (see <specref ref="data-model"/>).  If there is an
   error retrieving the resource, then the XSLT processor may signal an
   error; if it does not signal an error, it must recover by returning an
   empty node-set.  One possible kind of retrieval error is that the XSLT
   processor does not support the URI scheme used by the URI.  An XSLT
   processor is not required to support any particular URI schemes.  The
   documentation for an XSLT processor should specify which URI schemes
   the XSLT processor supports.</p>

If the significant text supporting a test is:

   When the first argument to the document function is not a node-set,
   the first argument is converted to a string as if by a call to the
   string function.

it spans a text node, an element node containing a text node, another
text node, another element node, and a portion of another text node.

I was going to ask how we were going to support identifying that span
of text, but in a rare moment of lucidity and in the interests of
keeping things simple (or simpler), I'm going to agree with Ken and
ask whether we can get by with associating the test with the <p>
containing the significant text.

 > >IDs rather than either XPointers or IDs that are XPointers in disguise
 > >would be more robust across versions of the specs.
 > Perhaps I should read your entire note before I begin answering. :{)}
 > >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.
 > But I've discovered that it wasn't XSLT used to create the XSLT 
 > Recommendation ... it is a DSSSL script using James' SGML semantics.  I've 
 > written the supplied address for Ben Trafford and it bounced as un-sendable.

I don't know where Ben Trafford comes into this, but surely a person
of your skill and experience could rewrite the DSSSL stylesheet as

 > >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.
 > Hmmmmmmmm ... let me think on that.  I may have to make that a separate 
 > document if I cannot combine both sets of requirements.

I thought that was always something that came up in conversation at
our meetings: that a user could or should be able to browse the text
of the Recommendations and see which tests apply to a particular run
of text in the Recommendation.


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