Yesterday

• 37 hours ago

  issue 5 (test="self::bogus" always succeeds) commented on by fgeor...@gmail.com   -   It seems the problem comes from the duality of @test. It is used either as a complete predicate test, or as a expression on the result value to select the item to be compared as if there where no @test. I think the ideal situation would be to have, either a @test with a complete predicate (must return one boolean), or either a @value to select a value to compare the result to or a content on the expect element for the same purpose, and in the last case (@value or content) the ability to have @select to select the exact item to compare from the result: <!-- case 1 --> <x:expect test="count(...) eq 2"/> <!-- case 2 --> <x:expect value="'value'"/> <!-- case 3 --> <x:expect value="'value'" select="string(.)"/> <!-- case 4 --> <x:expect> <result/> </x:expect> <!-- case 5 --> <x:expect select="elem/result"> <result id="..."/> </x:expect> Unfortunately @select is already used for the purpose of the above @value, and @test is used for the purpose of both the above @test and @select. Perhaps we should restrict @test to a predicate expression and define a new attribute for the above @select (selecting an item out of the result). But here I cannot find a good name, except @select ;-) Regards, -- Florent Georges http://www.fgeorges.org/

  It seems the problem comes from the duality of @test. It is used either as a complete predicate test, or as a expression on the result value to select the item to be compared as if there where no @test. I think the ideal situation would be to have, either a @test with a complete predicate (must return one boolean), or either a @value to select a value to compare the result to or a content on the expect element for the same purpose, and in the last case (@value or content) the ability to have @select to select the exact item to compare from the result: <!-- case 1 --> <x:expect test="count(...) eq 2"/> <!-- case 2 --> <x:expect value="'value'"/> <!-- case 3 --> <x:expect value="'value'" select="string(.)"/> <!-- case 4 --> <x:expect> <result/> </x:expect> <!-- case 5 --> <x:expect select="elem/result"> <result id="..."/> </x:expect> Unfortunately @select is already used for the purpose of the above @value, and @test is used for the purpose of both the above @test and @select. Perhaps we should restrict @test to a predicate expression and define a new attribute for the above @select (selecting an item out of the result). But here I cannot find a good name, except @select ;-) Regards, -- Florent Georges http://www.fgeorges.org/
• 38 hours ago

  issue 9 (Escape literal attributes or allow AVTs?) reported by fgeor...@gmail.com   -   Hi, The content of the x:param element in a call to a template or a function explicitely escapes the { and } characters in attribute values. But why? Why not declaring those literal elements as being able to use AVT? I have a concrete example for that use. I test a function that takes an element in parameter, which contains a URI. Those URIs are all relative to a context on a server. So I disable the escaping in mode="test:create-xslt-generator" and used the following test suite: <x:param name="base-uri" select=" 'http://www.expath.org/modules/http-client/test/request'"/> <t:scenario label="method-001"> <t:call function="http:send-request"> <t:param> <http:request href="{ $base-uri }/method-001" method="options"/> </t:param> ... <!-- all subsequent test uses $base-uri --> I can provide a patch if this is more clear. What do you think? Regards, -- Florent Georges http://www.fgeorges.org/

  Hi, The content of the x:param element in a call to a template or a function explicitely escapes the { and } characters in attribute values. But why? Why not declaring those literal elements as being able to use AVT? I have a concrete example for that use. I test a function that takes an element in parameter, which contains a URI. Those URIs are all relative to a context on a server. So I disable the escaping in mode="test:create-xslt-generator" and used the following test suite: <x:param name="base-uri" select=" 'http://www.expath.org/modules/http-client/test/request'"/> <t:scenario label="method-001"> <t:call function="http:send-request"> <t:param> <http:request href="{ $base-uri }/method-001" method="options"/> </t:param> ... <!-- all subsequent test uses $base-uri --> I can provide a patch if this is more clear. What do you think? Regards, -- Florent Georges http://www.fgeorges.org/
• 38 hours ago

  issue 8 (Accessing the result sequence through a variable) reported by fgeor...@gmail.com   -   Hi, I am not sure this is the right place to discuss that kind of issue, but I think this is at least better than in provate emails. Please point me to better options if any. I am concerned about the ways we can write expectations for a component (template or function) that returns more than one item. Actually I think we can't. Let's say you test a function that returns, in some cases, a sequence of 3 items: an particular element, a string, and a document node. We can use neither the content of the expect element, nor its @select, because we have more than one result item. And we cannot use @test as the result sequence is only provided as the context item, so by nature limited to one. What I did instead in XTC was to provide the exact result sequence via a variable: <x:scenario> ... <x:expect test="$x:result[1] instance of element()"/> <x:expect test="$x:result[1]"> <the-element/> </x:expect> <x:expect test="$x:result[2] eq 'the string'"/> <x:expect test="$x:result[3] instance of document-node()"/> <x:expect test="$x:result[3]"> <the-doc/> </x:expect> </x:scenario> Setting the result as the context item is a comfortable shortcut when the result is a sequence of one item, because we can rely on the context item instead of writing $x:result, but that implies that the result sequence is no more than one item. Because this assumption is not checked by the stylesheet generated by XSpec, that leads furthermore to weird reports when the result has several items (because it uses a xsl:for-each to set the context item). What I suggest is modifying the template generated for an expect element, by: 1/ adding a variable named $x:result, initialized with $actual-result (or just rename the param) 2/ set the context item with xsl:for-each only when count($x:result) eq 1; this is only useful when the result has really one item, and that will catch the error when we thought that would be the case but that is not and we did not check explicitely for that (by throwing an error because the test expression tries to access the context item and it is not set). I can provide a patch if this is more clear. What do you think? Regards, -- Florent Georges http://www.fgeorges.org/

  Hi, I am not sure this is the right place to discuss that kind of issue, but I think this is at least better than in provate emails. Please point me to better options if any. I am concerned about the ways we can write expectations for a component (template or function) that returns more than one item. Actually I think we can't. Let's say you test a function that returns, in some cases, a sequence of 3 items: an particular element, a string, and a document node. We can use neither the content of the expect element, nor its @select, because we have more than one result item. And we cannot use @test as the result sequence is only provided as the context item, so by nature limited to one. What I did instead in XTC was to provide the exact result sequence via a variable: <x:scenario> ... <x:expect test="$x:result[1] instance of element()"/> <x:expect test="$x:result[1]"> <the-element/> </x:expect> <x:expect test="$x:result[2] eq 'the string'"/> <x:expect test="$x:result[3] instance of document-node()"/> <x:expect test="$x:result[3]"> <the-doc/> </x:expect> </x:scenario> Setting the result as the context item is a comfortable shortcut when the result is a sequence of one item, because we can rely on the context item instead of writing $x:result, but that implies that the result sequence is no more than one item. Because this assumption is not checked by the stylesheet generated by XSpec, that leads furthermore to weird reports when the result has several items (because it uses a xsl:for-each to set the context item). What I suggest is modifying the template generated for an expect element, by: 1/ adding a variable named $x:result, initialized with $actual-result (or just rename the param) 2/ set the context item with xsl:for-each only when count($x:result) eq 1; this is only useful when the result has really one item, and that will catch the error when we thought that would be the case but that is not and we did not check explicitely for that (by throwing an error because the test expression tries to access the context item and it is not set). I can provide a patch if this is more clear. What do you think? Regards, -- Florent Georges http://www.fgeorges.org/
• 47 hours ago

  r53 (Now merges adjacent text nodes when comparing actual and exp...) committed by jeni.tennison   -   Now merges adjacent text nodes when comparing actual and expected results

  Now merges adjacent text nodes when comparing actual and expected results

Last 30 days

• Dec 14, 2009

  r52 (Added two summaries of results for instant gratification. A...) committed by dev.xs...@menteithconsulting.com   -   Added two summaries of results for instant gratification. Added two 'callback' functions for handling @pending and separator between scenario texts so can be customised by using a stylesheet that imports this stylesheet, e.g.: <?xml version="1.0" encoding="UTF-8"?> <xsl:stylesheet version="2.0" xmlns:xsl="http://www.w3.org/1999/XSL/Transform" xmlns:xs="http://www.w3.org/2001/XMLSchema" xmlns:x="http://www.jenitennison.com/xslt/xspec" exclude-result-prefixes="x xs" xmlns="http://www.w3.org/1999/xhtml"> <xsl:import href="format-xspec-report.xsl" /> <xsl:param name="ticket-url" select="'https://example.com/ticket/%d'"/> <xsl:function name="x:pending-callback" as="node()*"> <!-- returns formatted output for $pending. --> <xsl:param name="pending" as="xs:string?"/> <xsl:if test="$pending"> <xsl:text>(</xsl:text> <strong> <!-- Turn ticket numbers into links to tickets. --> <xsl:analyze-string select="$pending" regex="#(\d+)"> <xsl:matching-substring> <xsl:variable name="ticket-number" select="regex-group(1)"/> <a href="{replace($ticket-url, '%d', $ticket-number)}">#<xsl:value-of select="$ticket- number"/></a> </xsl:matching-substring> <xsl:non-matching-substring> <xsl:value-of select="."/> </xsl:non-matching-substring> </xsl:analyze-string> </strong> <xsl:text>) </xsl:text> </xsl:if> </xsl:function> <xsl:function name="x:separator-callback" as="node()*"> <!-- returns formatted output for separator between scenarios. --> <span class="separator"><xsl:text> / </xsl:text></span> </xsl:function> </xsl:stylesheet>

  Added two summaries of results for instant gratification. Added two 'callback' functions for handling @pending and separator between scenario texts so can be customised by using a stylesheet that imports this stylesheet, e.g.: <?xml version="1.0" encoding="UTF-8"?> <xsl:stylesheet version="2.0" xmlns:xsl="http://www.w3.org/1999/XSL/Transform" xmlns:xs="http://www.w3.org/2001/XMLSchema" xmlns:x="http://www.jenitennison.com/xslt/xspec" exclude-result-prefixes="x xs" xmlns="http://www.w3.org/1999/xhtml"> <xsl:import href="format-xspec-report.xsl" /> <xsl:param name="ticket-url" select="'https://example.com/ticket/%d'"/> <xsl:function name="x:pending-callback" as="node()*"> <!-- returns formatted output for $pending. --> <xsl:param name="pending" as="xs:string?"/> <xsl:if test="$pending"> <xsl:text>(</xsl:text> <strong> <!-- Turn ticket numbers into links to tickets. --> <xsl:analyze-string select="$pending" regex="#(\d+)"> <xsl:matching-substring> <xsl:variable name="ticket-number" select="regex-group(1)"/> <a href="{replace($ticket-url, '%d', $ticket-number)}">#<xsl:value-of select="$ticket- number"/></a> </xsl:matching-substring> <xsl:non-matching-substring> <xsl:value-of select="."/> </xsl:non-matching-substring> </xsl:analyze-string> </strong> <xsl:text>) </xsl:text> </xsl:if> </xsl:function> <xsl:function name="x:separator-callback" as="node()*"> <!-- returns formatted output for separator between scenarios. --> <span class="separator"><xsl:text> / </xsl:text></span> </xsl:function> </xsl:stylesheet>

Older

• Nov 23, 2009

  WritingScenarios (How to write XSpec scenarios) Wiki page commented on by chriztian.steinmeier   -   I had a problem with a an expectation test that didn't seem to work: {{{ <x:expect label="it should add 'contain' to the class attribute" test="contains(/div/@class, 'contain')" /> }}} - report said: "Expected Result - ()", whereas if I wrote the test like this: {{{ <x:expect label="it should add 'contain' to the class attribute" test="/div[contains(@class, 'contain')]" /> }}} - it worked like a charm...

  I had a problem with a an expectation test that didn't seem to work: {{{ <x:expect label="it should add 'contain' to the class attribute" test="contains(/div/@class, 'contain')" /> }}} - report said: "Expected Result - ()", whereas if I wrote the test like this: {{{ <x:expect label="it should add 'contain' to the class attribute" test="/div[contains(@class, 'contain')]" /> }}} - it worked like a charm...
• Nov 11, 2009

  r51 (Fixed problem with namespace prefixes in generate-xspec-test...) committed by jeni.tennison   -   Fixed problem with namespace prefixes in generate-xspec-tests.xsl stylesheet.

  Fixed problem with namespace prefixes in generate-xspec-tests.xsl stylesheet.
• Nov 11, 2009

  r50 (Fix for bug that you get if you select something (eg a strin...) committed by jeni.tennison   -   Fix for bug that you get if you select something (eg a string) with curly braces in it.

  Fix for bug that you get if you select something (eg a string) with curly braces in it.
• Nov 05, 2009

  WritingScenarios (How to write XSpec scenarios) Wiki page commented on by cms...@blackmesatech.com   -   It might be helpful to mention that when an XML snippet is given as the content of 'expect' it needs to have a single root. (At least, in the current implementation the snippet is made into the content of an xsl:document element, and comparisons did not work when I wrote a context that selected several nodes and an expected result of two elements with specified content. Revising to make each test select one node and produce one element, or nothing, seems to have solved the problem.)

  It might be helpful to mention that when an XML snippet is given as the content of 'expect' it needs to have a single root. (At least, in the current implementation the snippet is made into the content of an xsl:document element, and comparisons did not work when I wrote a context that selected several nodes and an expected result of two elements with specified content. Revising to make each test select one node and produce one element, or nothing, seems to have solved the problem.)
• Oct 26, 2009

  UserGuide (A guide for users of XSpec) Wiki page commented on by cms...@blackmesatech.com   -   Suggestion: a list of known current limitations, issues, shortcomings, gotchas, and other items new users may trip on would be helpful. An entry in that list: If the stylesheet being tested has an xsl:output parameter with public and system identifiers for a DTD, they will show up in the report document (where they do not, strictly speaking, belong), complicating life for everyone.

  Suggestion: a list of known current limitations, issues, shortcomings, gotchas, and other items new users may trip on would be helpful. An entry in that list: If the stylesheet being tested has an xsl:output parameter with public and system identifiers for a DTD, they will show up in the report document (where they do not, strictly speaking, belong), complicating life for everyone.
• Jul 31, 2009

  r49 (Removed debugging messages!) committed by jeni.tennison   -   Removed debugging messages!

  Removed debugging messages!
• Jul 31, 2009

  r48 (Fixed bug whereby element content wasn't compared if its val...) committed by jeni.tennison   -   Fixed bug whereby element content wasn't compared if its value was '...', even if it contained element (or other) content.

  Fixed bug whereby element content wasn't compared if its value was '...', even if it contained element (or other) content.
• May 28, 2009

  issue 7 (Can't do 'x:scenario[x:context/@href]/x:scenario/x:context/*...) reported by dev.xs...@menteithconsulting.com   -   I don't understand the need for the restriction that a x:scenario can't have it's own x:context containing 'mock objects' if that x:scenario is nested inside a x:scenario that has a x:context that refers to an external file. The nesting of my x:scenario elements tends to follow the structure of the specification for the transform, and I'd rather choose internal or external contexts based on convenience instead of having to stick with one or the other. The error message is "can't set the context document using both the href attribute and the content of &lt;context&gt;"

  I don't understand the need for the restriction that a x:scenario can't have it's own x:context containing 'mock objects' if that x:scenario is nested inside a x:scenario that has a x:context that refers to an external file. The nesting of my x:scenario elements tends to follow the structure of the specification for the transform, and I'd rather choose internal or external contexts based on convenience instead of having to stick with one or the other. The error message is "can't set the context document using both the href attribute and the content of &lt;context&gt;"
• May 05, 2009

  r47 (Tidying up echoing of @label and @pending during a test run.) committed by dev.xs...@menteithconsulting.com   -   Tidying up echoing of @label and @pending during a test run.

  Tidying up echoing of @label and @pending during a test run.
• May 05, 2009

  r46 (Standardised on 'x' prefix for XSpec namespace. Re Issue 6.) committed by dev.xs...@menteithconsulting.com   -   Standardised on 'x' prefix for XSpec namespace. Re Issue 6.

  Standardised on 'x' prefix for XSpec namespace. Re Issue 6.
• May 05, 2009

  r45 (Added XSpec namespaces to list of omitted namespaces. Re Is...) committed by dev.xs...@menteithconsulting.com   -   Added XSpec namespaces to list of omitted namespaces. Re Issue 6.

  Added XSpec namespaces to list of omitted namespaces. Re Issue 6.
• Apr 02, 2009

  issue 6 (One less XSpec namespace in reported differences) reported by dev.xs...@menteithconsulting.com   -   At present, the markup in the 'Result' and 'Expecting' fragments always includes two namespace declarations for XSpec. This patch changes all s:* to x:* so there's only one namespace declaration for XSpec in each fragment. I haven't tried looking to find where to add 'exclude-namespace-prefixes' to get rid of that one. (And, of course, all of our tests always pass, so we never need to see it anyway.)

  At present, the markup in the 'Result' and 'Expecting' fragments always includes two namespace declarations for XSpec. This patch changes all s:* to x:* so there's only one namespace declaration for XSpec in each fragment. I haven't tried looking to find where to add 'exclude-namespace-prefixes' to get rid of that one. (And, of course, all of our tests always pass, so we never need to see it anyway.)
• Apr 01, 2009

  issue 5 (test="self::bogus" always succeeds) Labels changed by jeni.tennison   -   The user probably meant to write: <x:expect label="self::bogus" test="boolean(self::bogus)" /> which will only succeed if the result is a <bogus> element. What the user actually wrote was testing the result of the self::bogus expression (an empty sequence) against an empty sequence, which of course is always true. It's hard to know what to do to avoid users making this mistake, given that the current behaviour (if the result of the test isn't a boolean value, you are testing the result of that expression) is really useful. Perhaps if the result of the test isn't a boolean, there ought to be a requirement for the select attribute and/or content of <x:expect> to be present.

  Labels: Type-Enhancement Priority-Low −Type-Defect −Priority-Medium

  The user probably meant to write: <x:expect label="self::bogus" test="boolean(self::bogus)" /> which will only succeed if the result is a <bogus> element. What the user actually wrote was testing the result of the self::bogus expression (an empty sequence) against an empty sequence, which of course is always true. It's hard to know what to do to avoid users making this mistake, given that the current behaviour (if the result of the test isn't a boolean value, you are testing the result of that expression) is really useful. Perhaps if the result of the test isn't a boolean, there ought to be a requirement for the select attribute and/or content of <x:expect> to be present.

  Labels: Type-Enhancement Priority-Low −Type-Defect −Priority-Medium
• Apr 01, 2009

  issue 5 (test="self::bogus" always succeeds) reported by dev.xs...@menteithconsulting.com   -   This scenario always succeeds: <x:scenario label="This test should fail"> <x:context> <it-doesnt-really-matter/> </x:context> <x:expect label="self::bogus" test="self::bogus"/> </x:scenario> The test doesn't make much sense, but this was the style of the first tests that the user wrote.

  This scenario always succeeds: <x:scenario label="This test should fail"> <x:context> <it-doesnt-really-matter/> </x:context> <x:expect label="self::bogus" test="self::bogus"/> </x:scenario> The test doesn't make much sense, but this was the style of the first tests that the user wrote.
• Mar 27, 2009

  r44 (Fixed bug where 'report' output format wasn't provided.) committed by jeni.tennison   -   Fixed bug where 'report' output format wasn't provided.

  Fixed bug where 'report' output format wasn't provided.
• Mar 27, 2009

  r43 (Fixed a problem with the generation of external result docum...) committed by jeni.tennison   -   Fixed a problem with the generation of external result documents, in that it was adding XSpec markup to them. Now not.

  Fixed a problem with the generation of external result documents, in that it was adding XSpec markup to them. Now not.
• Mar 25, 2009

  issue 4 (Add @label to <x:description>?) commented on by dev.xs...@menteithconsulting.com   -   But then you'd probably end up repeating the label each place you import the tests. If you only import the tests in one place, it wouldn't make much difference. If you imported the same file into multiple places, the two alternatives would be a choice between an innocuous label in the imported tests or saying much the same thing on multiple x:import. Alternatively, you could allow both and use x:import/@label in preference to x:description/@label if both exist.

  But then you'd probably end up repeating the label each place you import the tests. If you only import the tests in one place, it wouldn't make much difference. If you imported the same file into multiple places, the two alternatives would be a choice between an innocuous label in the imported tests or saying much the same thing on multiple x:import. Alternatively, you could allow both and use x:import/@label in preference to x:description/@label if both exist.
• Mar 24, 2009

  issue 4 (Add @label to <x:description>?) commented on by jeni.tennison   -   What do you think about adding the label to the x:import instead? I'm not sure which makes more sense; just raising it as a possibility.

  What do you think about adding the label to the x:import instead? I'm not sure which makes more sense; just raising it as a possibility.
• Mar 24, 2009

  issue 4 (Add @label to <x:description>?) reported by dev.xs...@menteithconsulting.com   -   The first thing that I wanted to do when I split a bunch of tests into multiple files was label each group of imported tests. Since there is no x:description/@label, I had to add x:description/x:scenario around the 'real' x:scenario elements just to be able to use an @label to label all the tests in the file. So it seems to me that it would be simpler if x:description allowed @label. The @label of the top x:description could possibly then end up in the title of the HTML report.

  The first thing that I wanted to do when I split a bunch of tests into multiple files was label each group of imported tests. Since there is no x:description/@label, I had to add x:description/x:scenario around the 'real' x:scenario elements just to be able to use an @label to label all the tests in the file. So it seems to me that it would be simpler if x:description allowed @label. The @label of the top x:description could possibly then end up in the title of the HTML report.
• Mar 23, 2009

  WritingScenarios (How to write XSpec scenarios) Wiki page edited by dev.xs...@menteithconsulting.com
• Mar 22, 2009

  r41 (Changed behaviour when reporting results of large documents;...) committed by jeni.tennison   -   Changed behaviour when reporting results of large documents; these now get output as separate documents rather than embedded in the report, otherwise (for large results) Ant has problems opening the report to check whether the tests have succeeded or not. (It's also better for viewing the report, as these are now links to XML files rather than embedded serialised XML.)

  Changed behaviour when reporting results of large documents; these now get output as separate documents rather than embedded in the report, otherwise (for large results) Ant has problems opening the report to check whether the tests have succeeded or not. (It's also better for viewing the report, as these are now links to XML files rather than embedded serialised XML.)
• Mar 21, 2009

  r40 (Added support for <label> element as well as label attribute...) committed by jeni.tennison   -   Added support for <label> element as well as label attribute.

  Added support for <label> element as well as label attribute.
• Mar 21, 2009

  r39 (Fixed xspec.rnc to allow <x:like> elements within scenarios.) committed by jeni.tennison   -   Fixed xspec.rnc to allow <x:like> elements within scenarios.

  Fixed xspec.rnc to allow <x:like> elements within scenarios.
• Mar 21, 2009

  r38 (Fixed bug that prevented the use of shared scenarios.) committed by jeni.tennison   -   Fixed bug that prevented the use of shared scenarios.

  Fixed bug that prevented the use of shared scenarios.
• Mar 10, 2009

  r37 (ant script for running XSpec) committed by jeni.tennison   -   ant script for running XSpec

  ant script for running XSpec
• Feb 05, 2009

  r36 (Removed a couple of errors in regular expressions that were ...) committed by jeni.tennison   -   Removed a couple of errors in regular expressions that were spoiling the algorithm matching text to node in the coverage report.

  Removed a couple of errors in regular expressions that were spoiling the algorithm matching text to node in the coverage report.
• Feb 03, 2009

  r35 (Work on coverage reporting. It's still buggy, and won't work...) committed by jeni.tennison   -   Work on coverage reporting. It's still buggy, and won't work for large transformations due to memory issues, but it's a start.

  Work on coverage reporting. It's still buggy, and won't work for large transformations due to memory issues, but it's a start.
• Dec 29, 2008

  r34 (Updated serialization options to indent report; updated enco...) committed by jsulak   -   Updated serialization options to indent report; updated encoding to match stylesheets.

  Updated serialization options to indent report; updated encoding to match stylesheets.
• Dec 11, 2008

  r33 (Fixed problem with manual recursion in item:deep-equal() cau...) committed by jeni.tennison   -   Fixed problem with manual recursion in item:deep-equal() causing infinite recursion detection; used every...satisfies... instead.

  Fixed problem with manual recursion in item:deep-equal() causing infinite recursion detection; used every...satisfies... instead.
• Dec 11, 2008

  issue 3 (Contribution: XProc XSpec pipeline) changed by jeni.tennison   -   Thank you very much James. I've edited the Wiki to point to your description of integration into Oxygen, and added xspec.xpl to trunk (and put a link to it in the same page). If you'd like me to add you as a member of the project, so that you can make these kinds of changes yourself, please let me know your Google email address. Thanks, Jeni

  Status: Done

  Labels: Type-Enhancement −Type-Defect

  Thank you very much James. I've edited the Wiki to point to your description of integration into Oxygen, and added xspec.xpl to trunk (and put a link to it in the same page). If you'd like me to add you as a member of the project, so that you can make these kinds of changes yourself, please let me know your Google email address. Thanks, Jeni

  Status: Done

  Labels: Type-Enhancement −Type-Defect
• Dec 11, 2008

  RunningScenarios (How to test whether your stylesheet meets its description) Wiki page edited by jeni.tennison
• Dec 11, 2008

  r31 (XSpec XProc pipeline from James Sulak) committed by jeni.tennison   -   XSpec XProc pipeline from James Sulak

  XSpec XProc pipeline from James Sulak
• Dec 11, 2008

  RunningScenarios (How to test whether your stylesheet meets its description) Wiki page edited by jeni.tennison
• Dec 10, 2008

  issue 3 (Contribution: XProc XSpec pipeline) reported by jsulak   -   Hello Jeni, I've created a simple XProc pipeline to execute a XSpec test. I did not include any of the coverage report stuff because I didn't really understand it. I've attached the pipeline below. I've also written up instructions on how to integrate XSpec into Oxygen, which you are welcome to add to the wiki: http://www.wordsinboxes.com/2008/12/getting-started-with-xspec.html -James <p:pipeline xmlns:p="http://www.w3.org/ns/xproc" xmlns:c="http://www.w3.org/ns/xproc-step" xmlns:xs="http://www.w3.org/2001/XMLSchema" xmlns:t="http://www.jenitennison.com/xslt/xspec" name="xspec" type="t:xspec"> <p:documentation> <p>This pipeline executes an XSpec test.</p> <p><b>Primary input:</b> A XSpec test document.</p> <p><b>Primary output:</b> A formatted HTML XSpec report.</p> </p:documentation> <p:serialization port="result" encoding="utf-8" method="html" /> <p:xslt name="create-test-stylesheet"> <p:input port="stylesheet"> <p:document href="generate-xspec-tests.xsl"/> </p:input> </p:xslt> <p:xslt name="run-tests" template-name="t:main"> <p:input port="source"> <p:pipe step="xspec" port="source"/> </p:input> <p:input port="stylesheet"> <p:pipe step="create-test-stylesheet" port="result"/> </p:input> </p:xslt> <p:xslt name="format-report"> <p:input port="stylesheet"> <p:document href="format-xspec-report.xsl"/> </p:input> </p:xslt> </p:pipeline>

  Hello Jeni, I've created a simple XProc pipeline to execute a XSpec test. I did not include any of the coverage report stuff because I didn't really understand it. I've attached the pipeline below. I've also written up instructions on how to integrate XSpec into Oxygen, which you are welcome to add to the wiki: http://www.wordsinboxes.com/2008/12/getting-started-with-xspec.html -James <p:pipeline xmlns:p="http://www.w3.org/ns/xproc" xmlns:c="http://www.w3.org/ns/xproc-step" xmlns:xs="http://www.w3.org/2001/XMLSchema" xmlns:t="http://www.jenitennison.com/xslt/xspec" name="xspec" type="t:xspec"> <p:documentation> <p>This pipeline executes an XSpec test.</p> <p><b>Primary input:</b> A XSpec test document.</p> <p><b>Primary output:</b> A formatted HTML XSpec report.</p> </p:documentation> <p:serialization port="result" encoding="utf-8" method="html" /> <p:xslt name="create-test-stylesheet"> <p:input port="stylesheet"> <p:document href="generate-xspec-tests.xsl"/> </p:input> </p:xslt> <p:xslt name="run-tests" template-name="t:main"> <p:input port="source"> <p:pipe step="xspec" port="source"/> </p:input> <p:input port="stylesheet"> <p:pipe step="create-test-stylesheet" port="result"/> </p:input> </p:xslt> <p:xslt name="format-report"> <p:input port="stylesheet"> <p:document href="format-xspec-report.xsl"/> </p:input> </p:xslt> </p:pipeline>
• Dec 01, 2008

  r29 (Added an error message for when a good prefix can't be ident...) committed by jeni.tennison   -   Added an error message for when a good prefix can't be identified for a namespace.

  Added an error message for when a good prefix can't be identified for a namespace.
• Dec 01, 2008

  r28 (Changed the locations of the comments a little so that they'...) committed by jeni.tennison   -   Changed the locations of the comments a little so that they're picked up by Oxygen as applying to elements.

  Changed the locations of the comments a little so that they're picked up by Oxygen as applying to elements.
• Dec 01, 2008

  r27 (Work on a utility for automatically generating XSpec tests.) committed by jeni.tennison   -   Work on a utility for automatically generating XSpec tests.

  Work on a utility for automatically generating XSpec tests.
• Nov 22, 2008

  issue 2 (Unable to produce HTML report when testing a stylesheet that...) commented on by jsulak   -   No worries. I got the latest from the repository, and it indeed works for me now, too. Thanks, -James

  No worries. I got the latest from the repository, and it indeed works for me now, too. Thanks, -James
• Nov 12, 2008

  r26 (preserve-space attribute should be optional. Also changed de...) committed by jeni.tennison   -   preserve-space attribute should be optional. Also changed definition of msxsl:node-set() to deal better with sequences of nodes.

  preserve-space attribute should be optional. Also changed definition of msxsl:node-set() to deal better with sequences of nodes.
• Nov 09, 2008

  issue 2 (Unable to produce HTML report when testing a stylesheet that...) Status changed by jeni.tennison   -   Sorry for taking so long to get round to looking at this. I just tried to replicate this and couldn't. The generated test stylesheet uses <xsl:result-document> to create the report, and uses its own output format, which shouldn't (and doesn't, as far as I can tell) inherit the doctype directives from the stylesheet under test. Could you grab hold of the latest version from trunk and test whether you're still encountering this problem with it? If so, could you provide me with a sample stylesheet and XSpec which demonstrate the issue. Thanks, Jeni

  Status: WorksForMe

  Sorry for taking so long to get round to looking at this. I just tried to replicate this and couldn't. The generated test stylesheet uses <xsl:result-document> to create the report, and uses its own output format, which shouldn't (and doesn't, as far as I can tell) inherit the doctype directives from the stylesheet under test. Could you grab hold of the latest version from trunk and test whether you're still encountering this problem with it? If so, could you provide me with a sample stylesheet and XSpec which demonstrate the issue. Thanks, Jeni

  Status: WorksForMe
• Nov 04, 2008

  r25 (Customisable whitespace handling: use preserve-space on <x:d...) committed by jeni.tennison   -   Customisable whitespace handling: use preserve-space on <x:description> to list the QNames of elements that appear within <x:context>, <x:expect> or <x:param> whose child whitespace should be preserved. Also a bug fix to ensure that the templates from the generated test stylesheet override any of those in the stylesheet being tested. This is important if there are any mode="#all" templates in the stylesheet being tested.

  Customisable whitespace handling: use preserve-space on <x:description> to list the QNames of elements that appear within <x:context>, <x:expect> or <x:param> whose child whitespace should be preserved. Also a bug fix to ensure that the templates from the generated test stylesheet override any of those in the stylesheet being tested. This is important if there are any mode="#all" templates in the stylesheet being tested.
• Nov 04, 2008

  r24 (Added some better support for whitespace handling within XSp...) committed by jeni.tennison   -   Added some better support for whitespace handling within XSpecs. Whitespace within XSpec context and expected trees is now significant if the elements are XHTML spans and paragraphs. It's also possible to use <x:space> to mark whitespace that is significant either in the source or result. And still possible to use xml:space="preserve".

  Added some better support for whitespace handling within XSpecs. Whitespace within XSpec context and expected trees is now significant if the elements are XHTML spans and paragraphs. It's also possible to use <x:space> to mark whitespace that is significant either in the source or result. And still possible to use xml:space="preserve".
• Oct 17, 2008

  WritingScenarios (How to write XSpec scenarios) Wiki page edited by jeni.tennison
• Oct 16, 2008

  r22 (Another fix to xspec.bat to handle whitespace in Windows fil...) committed by jeni.tennison   -   Another fix to xspec.bat to handle whitespace in Windows file paths.

  Another fix to xspec.bat to handle whitespace in Windows file paths.
• Oct 08, 2008

  issue 2 (Unable to produce HTML report when testing a stylesheet that...) reported by jsulak   -   Hello Jeni, I am attempting to test a stylesheet that contains <xsl:output method="xml" version="1.0" encoding="utf-8" doctype-system="codebook2.dtd" doctype-public="-//JMP//DTD CodeBook v.8//EN"/> I can produce an XML test result, but it contains a doctype declaration matching the values in the xsl:output element: <?xml-stylesheet type="text/xsl" href="file:/C:/Documents%20and%20Settings/jsulak/My%20Documents/scripts/xspec-v0.1/format-xspec-report.xsl"?><!DOCTYPE s:report PUBLIC "-//JMP//DTD CodeBook v.8//EN" "codebook2.dtd"> When this XML test result is fed into format-xspec-report.xsl, it fails, since Saxon can't find the DTD. The root of the problem (I think) is that the testing transform produced by generate-xspec-tests.xsl imports the original transform using <xsl:import/>. Since the original transform does have @doctype-system and @doctype-public explicitly defined, the testing transform uses those values instead of the default empty values defined in the testing transform. I'm not sure how you would get around the problem. I experimented with placing <xsl:result-document /> inside of the "main" template, but no luck. If it helps, the output from the batch file is below: Started: "C:\Documents and Settings\jsulak\My Documents\scripts\xspec-v0.1\xspec.bat" "A:\XML Sandbox\Legislative Update\Pipeline\Code Cleanup\test_remove.xml" Creating Test Stylesheet... "c:\temp\xspec\test_remove.xsl" "A:\XML Sandbox\Legislative Update\Pipeline\Code Cleanup\test_remove.xml" Running Tests... Testing with SAXON 9.1.0.1 Annotations ..A group of annotations with categories Categories are propagated to the annotations; elements are renamed. No category elements in annotation root ..A group of annotations without categories Empty category elements are created No category elements in annotation root ..When an annotationinfo element is present, the order must be correct. Category comes after annotationinfo. Remove deprecated attributes Attribute removed Formatting Report... Error java.io.FileNotFoundException: c:\temp\xspec\codebook2.dtd (The system cannot find the file specified) Transformation failed: Run-time errors were reported '"c:\temp\xspec\test_remove-result.html"' is not recognized as an internal or external command, operable program or batch file. Done. Process ended with exit code: 0 I'm enjoying playing with XSpec, so keep up the good work. Thanks, -James

  Hello Jeni, I am attempting to test a stylesheet that contains <xsl:output method="xml" version="1.0" encoding="utf-8" doctype-system="codebook2.dtd" doctype-public="-//JMP//DTD CodeBook v.8//EN"/> I can produce an XML test result, but it contains a doctype declaration matching the values in the xsl:output element: <?xml-stylesheet type="text/xsl" href="file:/C:/Documents%20and%20Settings/jsulak/My%20Documents/scripts/xspec-v0.1/format-xspec-report.xsl"?><!DOCTYPE s:report PUBLIC "-//JMP//DTD CodeBook v.8//EN" "codebook2.dtd"> When this XML test result is fed into format-xspec-report.xsl, it fails, since Saxon can't find the DTD. The root of the problem (I think) is that the testing transform produced by generate-xspec-tests.xsl imports the original transform using <xsl:import/>. Since the original transform does have @doctype-system and @doctype-public explicitly defined, the testing transform uses those values instead of the default empty values defined in the testing transform. I'm not sure how you would get around the problem. I experimented with placing <xsl:result-document /> inside of the "main" template, but no luck. If it helps, the output from the batch file is below: Started: "C:\Documents and Settings\jsulak\My Documents\scripts\xspec-v0.1\xspec.bat" "A:\XML Sandbox\Legislative Update\Pipeline\Code Cleanup\test_remove.xml" Creating Test Stylesheet... "c:\temp\xspec\test_remove.xsl" "A:\XML Sandbox\Legislative Update\Pipeline\Code Cleanup\test_remove.xml" Running Tests... Testing with SAXON 9.1.0.1 Annotations ..A group of annotations with categories Categories are propagated to the annotations; elements are renamed. No category elements in annotation root ..A group of annotations without categories Empty category elements are created No category elements in annotation root ..When an annotationinfo element is present, the order must be correct. Category comes after annotationinfo. Remove deprecated attributes Attribute removed Formatting Report... Error java.io.FileNotFoundException: c:\temp\xspec\codebook2.dtd (The system cannot find the file specified) Transformation failed: Run-time errors were reported '"c:\temp\xspec\test_remove-result.html"' is not recognized as an internal or external command, operable program or batch file. Done. Process ended with exit code: 0 I'm enjoying playing with XSpec, so keep up the good work. Thanks, -James