Re: Comments on discretionary items list

[Tony Graham <tgraham@mulberrytech.com>]

At 11 Oct 2000 14:48 -0700, Kirill Gavrylyuk wrote:
 > Here are comments/suggestions on discretionary items list I promised on the
 > last meeting.
 > 
 > 
 > The following items seem not to fall into discretionary category
 > 	  signal-non-xslt-attribute-uri 		- spec says that
 > XSLT processor must ignore attributes without giving an error if it doesn't
 > recognize the namespace URI.

You are correct.  This item should be removed.

 > 	  signal-non-xslt-top-level-element-uri   - spec says that XSLT
 > processor must ignore top-level element without giving an error if it
 > doesn't recognize the namespace URI.

Correct again.

 > This one looks problematic as it is rather discretionary feature of the XML
 > processor and particular stylesheet then of XSLT/XPath processor:
 > 	
 > 	disc-xpath-default-attribute

Maybe it does depend on whether an XSLT/XPath processor is assumed to
always use the same XML processor, but I think that you are correct
and that it's out of scope.

 > This one is a statement of an unfortunate reality. I didn't study that
 > precisely, but I doubt that any of XSLT processor vendors can prove that
 > they are able to detect any infinite loop.
 > So it seem not to fall into discretionary category:
 > 
 > 	disc-detect-infinite-loop

The answers to the discretionary item questions are to be used to
determine which test cases to use for a processor.  All that a "yes"
answer would do is trigger inclusion of the infinite loop test cases.

It now seems that we'd have trouble detecting processors' detection of
infinite loops, since every processor could do something different
once it did detect the loop.

On the other hand, it would be a useful metric, but not really a
conformance metric, to see how many infinite loop test cases a
processor could detect and take appropriate action.

 > These discretionary items don't seem to be the basis for any kind of
 > conformance or interop testing:
 > 	disc-element-use-qname-prefix, disc-attribute-use-qname-prefix,
 > disc-generate-id, disc-non-result-tree-namespace-node, disc-resource-limit

It's already been pointed out that the questions are poor, but I think
that these items are meant to influence what the test suite considers
to be conformant output.  If you know that the processor is going to
add extra namespace nodes, you should give a pass/fail if the
processor has extra nodes.  Conversely, if you know not to expect
extra namespace nodes, finding them in the result could indicate
something.

 > For these two it is better to ask "What languages are supported ...?" and
 > "Which variation of sorting/number presentation is chosen for each
 > particular language". 
 > 
 > 	disc-convert-number, disc-sort

That's already been pointed out.

 > Though this item don't seem to be a basis of any kind of conformance testing
 > directly, we might have in the future some tests that depends on this item,
 > so it is better ask "How the implementation orders documents for document
 > function?", because the order IS implementation dependant.
 > 	
 > 	disc-different-document-node-document-order

I cast the questions as yes/no because that's what I'd done for the
"signal-" questions, but you are correct, it's better stated as a
request for how the nodes are ordered.

 > The answer for this one can be different for different signal-error
 > discretionary items, it should be asked in the corresponding discretionary
 > questions for each specific error handling. I saw example from Tony Graham
 > ("User's discretion" mail) that concur with that.
 > 	disc-error-recovery

Correct again.  Maybe the "signal-" questions should each have a
related question of "If yes, it is a fatal error?"

 > 
 > This item could be added as it is not controlled by XSLT recommendation.
 > 
 > ------------------------------------------------------------------------
 > disc-sort-qname
 > 
 > 10 Sorting  
 > .....
 > data-type specifies the data-type of the strings; the following values are
 > allowed:
 > ......
 > a QName with a prefix is expanded into an expanded-name as described in
 > [..]; the expanded-name identifies data-type' the behavior in this case is
 > NOT SPECIFIED BY THIS DOCUMENT.
 > 
 > Question: What is the behavior of XSLT processor in case it doesn't support
 > specified data-type for sort?

Yes, it should be added.

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
======================================================================