XSLT 2.0 Last Call Comments (First last-call Period)

Hi everyone.

Apologies if this is a FAQ.  Though I had a look through some archives
and didn't see anything relevant, I have a suspicion it would've been
asked before.

Has the XSL working group given thought to specifying incremental XSLT
processors in the recommendations, or have some sort of support for it?
By "incremental" I mean something like this[1], where a processor will
automatically update the output document as modifications to the source
document are made.

I can imagine situations where this would be useful.  For example, if an
XML document and a stylesheet are served to a browser, which converts the
document to XHTML to display, script in the XHTML could be used to do
manipulations of the higher level XML document and have the changes
propagated to the XHTML.

Thanks,

Cameron

[1] http://www2002.org/CDROM/refereed/321/

-- 
Cameron McCormack
|  Web: http://mcc.id.au/
|  ICQ: 26955922

    

            

**Action MK:  Indicate WG endorsed MK's earlier response rejecting
              the proposal, explaining WG's thinking.

         

Cameron McCormack raised this comment {qt-2003Nov0052-01}:

http://lists.w3.org/Archives/Public/public-qt-comments/2003Nov/0052.html

I made a personal reply at 

http://lists.w3.org/Archives/Public/public-qt-comments/2003Nov/0056.html

which reads:

Thanks for drawing my attention to this interesting paper.

I think it has always been part of the design philosophy of XSLT that by
keeping the language side-effect-free, incremental transformation would
be
possible. This paper seems to suggest that this assuption is correct. If
anyone wants to propose specific changes to the language that are needed
in
order to develop incremental processors, then the Working Group would be
happy to look at such suggestions. However, "specifying incremental XSLT
processors" is outside the WG's scope: we only specify the language, not
details of how implementations should work.

The Working Group considered the comment on 2004-01-20 and decided to
endorse my personal reply. This closes the comment with no change to the
specification.

Cameron, can you please confirm that this closure of the comment is
acceptable?

With regards,

Michael Kay

         Change status to "announced"
         

Hi Michael.

Kay, Michael:
> Cameron, can you please confirm that this closure of the comment is
> acceptable?

Yes, it is.  It was more of an out loud thought wondering how incremental
XSLT would stand in relation to the spec.

Thanks,

Cameron

PS: I must say that the thoroughness of response to comments by this WG
    is quite laudable, especially compared to some others whose mailing
    lists I follow.

-- 
Cameron McCormack

Would it be possible to define special picture parameters for the date
and time formatting methods such as "long" "medium" "short". The XSL
processor can use this in combination with the language and country
parameters to produce a localized format for a particular locale.

An example of this is the java class java.util.text.DateFormat which
can produce DateFormats based on the styles DateFormat.LONG,
DateFormat.MEDIUM, DateFormat.SHORT and a java.util.Locale which can
be constructed from the language and country.

Another example is C#'s String.Format with D,d,T,t,F,f for long and
short date, time, date and time.

Another example is in vb with DateFormat Enumeration's vbLongDate,
vbShortDate, vbLongTime and vbShortTime.

This will allow authors of style sheets to format dates and times
based on a users preferred formats and not have to hard code formats
in style sheets.

If the implementation does not have the ability to determine a
localized format then it could fall back to a predefined one.

A similar thing could be done with number formats.

    

Richard Zschech raised this comment {qt-2003Nov0055-01}:

http://lists.w3.org/Archives/Member/w3c-xsl-wg/2004Jan/0031.html

The Working Group considered this proposal on 2004-01-20 and decided not
to add the new functionality requested.

There were a number of reasons:

(a) It would be difficult to make any kind of definitive statement of
what "short", "medium", and "long" were supposed to mean, other than by
example

(b) We don't currently have any functionality that depends explicitly on
the user's locale or localization preferences, and it would be difficult
to define this concept

(c) We felt the required functionality could easily be provided by a
function library sitting on top of the current date/time formatting
functionality that is already provided: in other words, it was non-core.

Richard: thank you for raising the comment. I would be grateful if you
could confirm that this response is acceptable.

Regards,

Michael Kay

            
 
**Action MK:  Respond to this rejecting proposal, explaining WG's
              rationale.
         

         Status changed to "announced".
         

Richard Zschech sent the following response to my personal email
address; I am forwarding it to the list for the archives. - MK

-----Original Message-----
From: Richard Zschech [mailto:richard.zschech@cqrdata.com] 
Sent: 26 January 2004 11:54
To: Kay, Michael
Subject: Re: [XSLT 2.0] format-dateTime localised picture parameters


Sorry about the resend. Here is is without the formatting |s

Kay, Michael wrote:

> Richard Zschech raised this comment {qt-2003Nov0055-01}:
>
> http://lists.w3.org/Archives/Member/w3c-xsl-wg/2004Jan/0031.html
>
> The Working Group considered this proposal on 2004-01-20 and decided 
> not to add the new functionality requested.
>
> There were a number of reasons:
>
> (a) It would be difficult to make any kind of definitive statement of 
> what "short", "medium", and "long" were supposed to mean, other than 
> by example
>
>  
>

I would define the meaning of "short", "medium", and "long" as follows 
based on section 16.5.2 (The language, calendar, and country arguments):

The "short", "medium", and "long" picture strings are used as aliases to

language and country dependent picture strings.

The language is used to select the appropriate language-dependent forms 
of the "short", "medium", and "long" picture strings. The function being

called should also be used to determine the type defendant form, for 
example "format-dateTime", "format-date", and "format-time" should 
produce date/time, date, and time picture strings. Where appropriate 
this choice may also take into account the value of the country 
argument, though this should not be used to override the language or any

sublanguage that is specified as part of the language argument.

The choice of the aliased picture strings for any given language is 
implementation-defined. For example, one implementation might alias  
"short" as "[M]-[D]-[Y]" while another uses "[M01]-[D01]-[Y0001]". 
Implementations may provide mechanisms allowing users to control such 
choices.



Given that other date formatting is implementation dependent, I don't 
think that this is an issue. For example, with month abbreviations, one 
implementation might abbreviate July as Jul while another uses Jly. In 
German, one implementation might represent Saturday as Samstag while 
another uses Sonnabend.

> (b) We don't currently have any functionality that depends explicitly 
> on the user's locale or localization preferences, and it would be 
> difficult to define this concept
>  
>

Maybe locale was the wrong word to use - language and country are 
sufficient.

> (c) We felt the required functionality could easily be provided by a 
> function library sitting on top of the current date/time formatting 
> functionality that is already provided: in other words, it was 
> non-core.
>  
>

Providing the functionality in a library would be possible but 
inelegant. The library writer would have to create a table of picture 
strings for all the combinations of language, country and picture alias.

Also, doing the formatting would require calling the library like so, 
format-time($t, picture("short", "en", "gb"), "en", (), "gb"), which is 
a bit messy.

The XSLT Requirements section 2.2 (Must Add Date Formatting Functions) 
says:" Functionality similar to that provided by 
java.text.SimpleDateFormat." which includes support for language and 
country "short", "medium", and "long" formatting.  The use case refers 
to formatting "according to the current locale" as well. If this is a 
"must" requirement then it should be core functionality and not provided

by a library.

> Richard: thank you for raising the comment. I would be grateful if you

> could confirm that this response is acceptable.
>
> Regards,
>
> Michael Kay
>  
>
I respectively ask the working group to reconsider this issue based on 
my arguments.

Thanks, from Richard.

      Summary: The WG discussed various approaches including the idea of using system properties.
        MK took an action to develop a proposal.
 
      

MK proposed this week http://lists.w3.org/Archives/Member/w3c-xsl-wg/2004Jun/0079.html.  How do we describe the semantics?  SB quotes Visual Basic's description of long:
displays a date using your locale's long-date format.
RESOLVED: to adopt MK's proposal, amended to allow for 'FULL' as well as short, medium, long.

Subsequent history:

Decision announced

Jeni Tennison pointed out that the design didn't do what the proposer intended

The proposer didn't like the answer

[23 Sep 2004] XSL WG telcon decided to reject the proposal

Revised decision announced


     
      

<xsl:template match="equation">
  <xsl:param name="equation-format" select="'(1)'" tunnel="yes"/>
  <xsl:number level="any" format="{$format}"/>
typo:
                                    $equation-format
</xsl:template>

            
Thanks for the comment. I have corrected this error in the example, and have marked the issue
as closed. I trust this meets with your approval.
         

Status changed to "announced"

Status changed to "acknowledged"

I think that the country argument should be removed from the date
formatting functions in 16.5 of the XSLT 2.0 draft.


<http://www.w3.org/TR/xslt20/#lang-cal-country>:
> The intended use of the country argument is to identify the place
> where an event [...] took place or will take place. [...] For
> example, different countries using the Old Style (Julian) calendar
> started the new year on different days,[...]  The geographical area
> identified by an ISO 3166-1 country code is defined by the
> present-day boundaries of that country, not by the boundaries as
> they existed historically.

The functionality you describe in this paragraph is indeed
interesting, but two questions arise: 1) Who is going to implement
it? and 2) Doesn't the issue of the last sentence destroy the whole
thing?

As to the first point, do you have a particular source in mind for
implementing these formatting routines? To me it seems like extensive
research would be necessary to compile a table of useful corrections
from the information of the country argument. If you think that this
argument is important you should provide a reference implementation.

As to the second point, event with the addition of the the ISO 3166-3
list of old countries (which I'm not sure how complete it is), is a
single country designation really precise enough? What about regional
variance? Your aim is set so high, yet I don't get a clear picture of
what the goal is.

My guess is that someone really needing this functionality will want
to provide the textual representation of the dates himself, probably
in the local language of the original event.

And probably more likely is that, since I presume that noone will
ever implement the wanted behaviour, there will be corrupted data
as people enter non-proleptic dates to get the right display. Show me
an implementation, and I will be glad to be wrong.

Yours sincerely,
Mikael Sterner

 

Personally, I have some sympathy with your comments. I do have doubts about
whether people who want to manage dates in non-Gregorian calendars will
actually want to use the schema date/time data types, and about whether
there is any benefit in providing conversions from Gregorian dates to other
calendars without also providing conversion in the opposite direction. As an
amateur genealogist myself, I know that I would never choose to store
historical data using proleptic Gregorian dates. 

I think the goals are clear: we are trying to ensure that there is enough
flexibility to cover all the ways that dates are actually represented by
different communities. But your objection, that we haven't done the research
to actually show how the parameters to these functions will be used, is
quite valid.

The W3C process does demand that specs be proven to be implementable.

Thanks for the comment, and I'm sure there will be further debate in the
working group. As I'm sure you can guess, there has been a great deal
already.

Discussion in XSL F2F in Tampa: 
  Minutes


   

            
 
Action AB:  produce a draft response.
         

Below is a draft response to the last call comment:

 qt-2003Nov0301-01 format-date() - country

I have exchanged various emails with the commentor to clarify both his comment and to explain our design rationale and aims. His last email is:

To:      Anders Berglund/Watson/IBM@IBMUS
Subject: Re: XSLT: your comment on "country" in date formatting functions

Anders Berglund wrote:
> point 1: you accept the argument that it is reasonable to provide the 
> country parameter as it is needed for complete and correct support of 
> many calendars.

Yes.

> point 2: you accept the corrected sentence as resolving your comment.

Yes.

Thanks,
Mikael Sterner


=== Draft Response to comment: qt-2003Nov0301-01 format-date() - country ===

[We may wish to exclude the first part from the formal response and just respond to the two specific points made]

Underlying your comment seems to be a question on the intent of the WG as to the scope of support of date formatting and the usecases that we aim to support in the first version of these functions (the design has been made in a way that it can be extended in a natural way to support much more). As noted below we expect vendors to implement the set that is appropriate for their markets so read the usecases with that in mind.

- quite complete support for displaying dates and times in the
  Gregorian calendar according to the conventions of a large
  number of countries.

- support for displaying "todays" and recent dates according to the
  conventions of calendars used in the last century or two and according
  to the conventions of a large number of countries
  (as we are based on the W3C Schema datatypes you achieve "todays" date
  by getting the current Gregorian dateTime and formatting this
  with the appropriate parameters).

- support for displaying a "historical" Gregorian date with a
  "reasonable" support of calendars and conventions.

  We are not expecting applications of eg old genealogy data to be using
  the Gregorian date (only). Applications, where it is important
  to have an unambigous value, would probably record both.

  We have not tackled converting the string of a "displayed" date into
  a dateTime schema type. This gets rather complex - and sometimes
  ambiguous; e.g. when the full set of digits for the year is not
  present. It is useful functionality but for the first version it
  was felt to be a bit too much!


To address your specific points:

Point 1:

You are quite right to observe that extensive research is required to identify the influence of the "country" argument if an implementation wished to support ALL possible values. A similar situation is present for e.g. collations, where it would be an almost insurmountable task to identify and implement correct linguistic collations for ALL languages.

The first sentence of 16.5.2 states the expectations of the WG as to who is going to implement the various parts of date formatting functionality; we expect vendors to determine the markets that they wish to support and implement accordingly. To take a specific example:

A vendor whose Thai market is important would support the Thai language, the Buddhist Era calendar, and the Thailand country code (the last one to support the change of the date of the new year which took place in 1941). Note that without the country parameter you have no reasonable way of enabling a vendor to support this "correction" to a rather recent date! To use xml:lang for this would be wrong!

Point 2:

You are correct that the last sentence is misleading. It should read:

  The geographical area identified by a country code is defined by the
  boundaries as they existed at the time of the date to be formatted,
  or the present-day boundaries for dates in the future.

This is the official response from the XSL Working Group.

The XSL WG reviewed your comment on 2004-02-12 and found that
for point 1. it is reasonable to provide the country parameter,
as is is needed for complete and correct support for many calendars
and that the parameter should be retained. For point 2. the WG
accepted that the text is incorrect and needs text change.
For detailed responses on each point see below.

We trust that this meets with your approval.

Point 1:

You are quite right to observe that extensive research is required
to identify the influence of the "country" argument if an implementation
wished to support ALL possible values. A similar situation is present
for e.g. collations, where it would be an almost insurmountable task
to identify and implement correct linguistic collations for ALL
languages.

The first sentence of 16.5.2 states the expectations of the WG as
to who is going to implement the various parts of date formatting
functionality; we expect vendors to determine the markets that they
wish to support and implement accordingly. To take a specific example:

A vendor whose Thai market is important would support the Thai
language, the Buddhist Era calendar, and the Thailand country code
(the last one to support the change of the date of the new year
which took place in 1941). Note that without the country parameter
you have no reasonable way of enabling a vendor to support this
"correction" to a rather recent date! To use xml:lang for this would
be wrong!

Point 2:

You are correct that the last sentence is misleading. It should read:

  The geographical area identified by a country code is defined by the
  boundaries as they existed at the time of the date to be formatted,
  or the present-day boundaries for dates in the future.
  
  
Note: document has been updated with this change 2004-02-13 - MHK  
  

        Status changed to "announced".
         

    Apparently we made and announced a decision and didn't hear back.

ACTION: Anders Berglund to confirm that this issue is in fact closed.


      

AB confirms that the poster accepted our response rejecting the comment; this happened
sometime between January and March (Feb 11?).
Close action.
See http://lists.w3.org/Archives/Member/w3c-xsl-wg/2004Feb/0012

      

The example states that the output should be:

<title><![CDATA[This is not ]]><hr/><![CDATA[ good coding practice]]></title>


which appears to have been doubly escaped.

Shouldn't it be


<title><!{CDATA{This is not }}><hr/><!{CDATA{ good coding practice}}></title>

[MHK: replaced square brackets by curlies in the above line]

I don't see anything in the example that should stop the title element
tags appearing normally rather than quoted with lt and gt.

David

            
Thanks for the comment. I have corrected this error in the example, and have marked the issue
as closed. I trust this meets with your approval.
         

Status changed to "announced"

Status changed to "acknowledged"

These issues came up as a result of discussion of a proposed clarification to
the EXSLT node-set() function specification [1]:

1. XSLT 2.0 says that fn:id() is supposed to work on a temporary tree [2]. I
do not see how any unique IDs that this function needs are going to be found
in the temporary tree. It's not possible for one to associate a DTD or other
schema with a temporary tree in order to force ID-ness or other type
information onto the attribute nodes in it, correct? So I would expect that
fn:id() would never return any nodes, when the context item is a node from the
temporary tree, since there are no unique IDs in the temporary tree. If I'm
correct, here, I propose that you add a note about this to XSLT 2.0.

2. I'm actually having trouble finding where in the XPath 2.0 specs there is
any discussion of the mechanism of assignment of unique IDs (as would be used
by fn:id()) to nodes. Appendix B of the function spec says "The recognition of
a node as an id value is sensitive to the manner in which the datamodel is
constructed", but the data model spec says only that "[Node identity] should
not be confused with the concept of a unique ID, which is a unique name
assigned to an element by the author to represent references using ID/IDREF
correlation"; nothing else, AFAIK. Did I miss something?

[1] http://lists.fourthought.com/pipermail/exslt/2003-December/000982.html
    http://lists.fourthought.com/pipermail/exslt/2003-December/000983.html
[2] http://www.w3.org/TR/xslt20/#temporary-trees

    

            
DECISION: MK will explain to the commentor and evaluate whether to include in spec.
         

The original comment {qt-2003Dec0117-01}:

http://lists.w3.org/Archives/Public/public-qt-comments/2003Dec/0117.html

came from Mike Brown. This is the official response from the XSL Working
Group.

The WG considered that no change was needed to the language
specification, but asked the editor to consider adding a clarifying note
or example.

In response to the questions:

1. XSLT 2.0 says that fn:id() is supposed to work on a temporary tree
[2]. I
do not see how any unique IDs that this function needs are going to be
found
in the temporary tree. It's not possible for one to associate a DTD or
other
schema with a temporary tree in order to force ID-ness or other type
information onto the attribute nodes in it, correct? So I would expect
that
fn:id() would never return any nodes, when the context item is a node
from the
temporary tree, since there are no unique IDs in the temporary tree. If
I'm
correct, here, I propose that you add a note about this to XSLT 2.0.

Response: if you validate an element or attribute in a temporary tree,
by using the validation or type attributes on a relevant XSLT
instruction, and if as a result of validation the node acquires a type
annotation of xs:ID, then the fn:id() function when applied to that
temporary tree has the ability to locate this node. At its simplest, you
can do:

<xsl:variable name="temp">
  <a>
    <xsl:attribute name="id" type="xs:ID" select="ABC"/>
  </a>
  <b>
    <xsl:attribute name="id" type="xs:ID" select="XYZ"/>
  </b>
</xsl:variable>

and then the call $temp/id('ABC') will find element <a>.

I propose to add an example along these lines to XSLT section 19.2.1.

2. I'm actually having trouble finding where in the XPath 2.0 specs
there is
any discussion of the mechanism of assignment of unique IDs (as would be
used
by fn:id()) to nodes. Appendix B of the function spec says "The
recognition of
a node as an id value is sensitive to the manner in which the datamodel
is
constructed", but the data model spec says only that "[Node identity]
should
not be confused with the concept of a unique ID, which is a unique name
assigned to an element by the author to represent references using
ID/IDREF
correlation"; nothing else, AFAIK. Did I miss something?

Response: The description of the fn:id() function in Functions and
operators states:

The result of the function is a sequence, in document order, of those
elements that are in the same document as the context node, and that
have an ID value equal to one or more of the IDREFs in the list of
candidate IDREFs. An element has an ID value of V if it has an attribute
whose type is xs:ID and whose value is V, or if the element itself is of
(simple) type xs:ID  and has a value of V.

The phrase "an attribute whose type is xs:ID" means that the attribute
must have a type annotation that is xs:ID or a type derived by
restriction from xs:ID. As explained in XSLT section 19.2.1, an
attribute node acquires such a type annotation as a result of
validation.

Could you confirm that you are happy with this explanation?

Thank you for raising the comment.

Michael Kay    
    
    

Status changed to "announced"

Kay, Michael wrote:
> The original comment {qt-2003Dec0117-01}:
> 
> http://lists.w3.org/Archives/Public/public-qt-comments/2003Dec/0117.html
> 
> came from Mike Brown. This is the official response from the XSL Working
> Group.
> 
> The WG considered that no change was needed to the language
> specification, but asked the editor to consider adding a clarifying note
> or example.
> 
> In response to the questions:
> [...]
> The phrase "an attribute whose type is xs:ID" means that the attribute
> must have a type annotation that is xs:ID or a type derived by
> restriction from xs:ID. As explained in XSLT section 19.2.1, an
> attribute node acquires such a type annotation as a result of
> validation.
>
> Could you confirm that you are happy with this explanation?

Mostly. It matches the comments initially made in the original thread, but I
found your response [1] to my inquiry about XSLT sec. 192.2.2 [2] to be just
as enlightening and IMHO equally worthy of inclusion in whatever action is
taken.

Thanks for the consideration and kind reply.

-Mike B.

[1] http://lists.w3.org/Archives/Public/public-qt-comments/2003Dec/0134.html
[2] http://lists.w3.org/Archives/Public/public-qt-comments/2003Dec/0129.html     
    

second bullet recomends
<xsl:if test="number(system-property('xsl:version')) < 2.0">, 

which is not well formed.

David


    

            
Thanks for the comment. I have corrected this error in the recommended code, and have marked the issue
as closed. I trust this meets with your approval.
         

Changed status to "announced"

Changed status to "acknowledged"

Section 1 says:


  [Definition: A transformation in the XSLT language is expressed in the
  form of a stylesheet, whose syntax is well-formed XML [XML 1.0]
  conforming to the Namespaces in XML Recommendation [XML Namespaces
  1.0].] 


Is it intentional that a stylesheet has to be xml 1.0, so presumably
may not be expressed in xml 1.1 (or later) even though source and result
documents may be xml 1.1 (if the system supports that)

Section 4.1 says

   Construction of the data model is outside the scope of this
   specification, so XSLT 2.0 places no formal requirements on an XSLT
   processor to accept input from either XML 1.0 documents or XML 1.1
   documents or both.

This leads to a more general question, should the stylesheet modules be
instances of the data model (rather than XML documents matching the
production in the XML spec). If they were defined this way, 4.1 would
apply and so the xml version number would be unconstrained (as would one
or two other things presently, such as white space handling, but that is
the subject of a separate comment)


In practice several systems allow in-memory modification of the
stylesheet as a DOM of some sort, after it has been parsed but before it
is applied, so specifying that the stylesheet is an instance of the DM
might in fact be closer to current practice than specifying that it must
be a document matching the productions in the XML spec.


David

    

Thanks for the comment. Unofficial interim response: 

We had some debate on this question and I think the results were somewhat
inconclusive. We need to sort this out.

The danger is that if we specify that the stylesheet is a DM document,
rather than serial XML, then that's one more place for little
interoperability problems to creep in. But we do tend to describe the
semantics of instructions on the assumption that they are nodes in a tree,
so I think it makes sense to go down that route.

Michael Kay

Further response from WG on 2004-01-25:
http://lists.w3.org/Archives/Public/public-qt-comments/2004Jan/0351.html

David Carlisle raised this comment at:

http://lists.w3.org/Archives/Public/public-qt-comments/2003Dec/0120.html

The WG considered the comment on 2004-01-20 and agreed that the current
wording of the specification was inadequate and inconsistent.

The editor was actioned to provide revised wording, which the WG will
review. This needs to balance the need to provide interoperability by
requiring all XSLT processors to accept stylesheet modules in the form
of lexical XML documents, while also allowing the flexibility for
stylesheet modules to be provided in other forms, e.g. as a document in
the data model, or as a DOM, or as a lexical XML 1.1 document.

The intention is to allow stylesheet modules to be expressed as XML 1.1
documents, but not to require XSLT 2.0 processors to accept such
stylesheets.

We are leaving the comment open for the time being.

Regards,

Michael Kay

            
The editor was actioned to provide revised wording, which the WG will
review. This needs to balance the need to provide interoperability by
requiring all XSLT processors to accept stylesheet modules in the form
of lexical XML documents, while also allowing the flexibility for
stylesheet modules to be provided in other forms, e.g. as a document in
the data model, or as a DOM, or as a lexical XML 1.1 document.
         

> 2003Dec0120-01 Stylesheet as data model instance
> 
>    Agreed in principle, action on editor to come up with the wording


      

qt-2003Dec0120-01: [XSLT2.0] XML versions and XSLT stylesheet as a data model instance
Does a stylesheet begin as an infoset or as a data model?
MK proposed in email from airport. http://lists.w3.org/Archives/Member/w3c-xsl-wg/2004Jun/0078.html
Long discussion of conformance issues.  
CONSENSUS on: input, output, and stylesheet should be handled
in parallel ways, e.g. require support for data model at the interface and allow support 
for XML at the interface.
No final decision until MK has a chance to to draft something and we can review it.

=================================================================
EXCERPT FROM MINUTES OF 15 JULY 2004

Issue closed. Text in
  http://lists.w3.org/Archives/Member/w3c-xsl-wg/2004Jul/0010.html
accepted.

==================================================================

      

> 16.1 Multiple Source Documents
has the reference

     As described in 2.3 Initiating a Transformation, the media type is
     available as part of the evaluation context for a transformation.


Which confused me as I couldn't see anything in 2.3 of relevance.

I think this is supposed to be a link to
5.3.2 Initializing the Dynamic Context
specifically, its last paragraph.



16.1 has several comments such as


    then the fragment identifier is interpreted according to the rules
    for the media type of the resource identified by the URI,

    [ERR XT1190] It is a non-recoverable dynamic error if a resource
    contains octets

which are slightly problematical as (not wanting to start a www-tag
style thread on the semantics of uris) Resources are not returned, only
representations of resources and the media type is attached to
the representation that is returned, not the resource itself. In
particular several different representations, with different media
types, can be returned for the same uri depending on what media types
you say you can accept in your (typically http) request.

However I think that the paragraph in 5.3.2 (once I'd found it:-)
addresses that as it indicates that as far as the processor is concerned
each uri is either unkown or will have a private mapping that will
specify one representation with one media type. But perhaps a slight
re-wording here would help.

David


    

Thanks for the comment. We'll see what can be done to tighten up the
wording.

Michael Kay

            
  
**Action MK:  Propose revisions that clarify existing text in last
              paragraph of 5.3.2, and modify 16.1 to point to 5.3.2.
         

David Carlisle raised this comment {qt-2003Dec0130-01} at:

http://lists.w3.org/Archives/Public/public-qt-comments/2003Dec/0130.html

This is the official response from the Working Group, which considered
the comment on 2004-01-20.

The editor was asked to propose revisions that clarify existing text in
last              paragraph of 5.3.2, and modify 16.1 to point to 5.3.2.

I think we also need some changes to section 2.3.

XPath 2.0 formalizes the context-dependency of the fn:doc() function
using the notion of the "available documents" as part of the dynamic
context. This essentially models the web as a collection of (URI,
document) pairs, and says that the effect of the doc() function is to
get the document node corresponding to a given URI; all the machinery to
achieve this (including URI dereferencing, XML parsing and validation)
is regarded as part of the environment or context, and is inherently
implementation-dependent.

Because the document() function supports fragment identifiers, and the
meaning of a fragment identifier depends on the media type of the
document, we need to extend the context so that instead of (URI,
document) pairs, it contains (URI, document, media-type) triples. This
needs to be defined as part of the input to a transformation in section
2.3. Section 5.3.2, which explains how we initialize the dynamic context
for XPath, then needs to say that the available documents for XPath is
the projection of this table containing only the URI and document parts.
The reference in Section 16.1, which describes the document() function,
to section 2.3 can then remain, and a reference to section 5.3.2 can be
added.

The proposed revisions are as follows:

Section 2.3:

Add to the list of information items supplied when a transformation is
initiated:

* The available documents. This represents the total set of documents
accessible to the stylesheet by means of a URI supplied as an argument
to the doc() or document() functions. This information can be modeled as
a function that takes an absolute URI as input; if the document exists
then it returns a document node and a media type, otherwise it returns
an indication that the document does not exist. The set of documents
that are available to the stylesheet is implementation-dependent, as is
the processing that is carried out to get a document node representing
the resource retrieved using a given URI. Some possible ways of
constructing a document from an XML representation are described in
[Data Model].

Section 5.3.2:

Change this to say that the available documents in the XPath Context is
provided from the available documents supplied when the transformation
was initiated, as described in section 2.3; and to say that XSLT
augments the XPath-defined "available documents" information in the
dynamic context by adding for each URI a media type.

Section 16.1:

Explain the use of media type in relation to the definitions in 2.3 and
5.3.2.

I don't think we need to go into issues of resources vs resource
representations. This formalism of modeling the web as a mapping of URIs
to (document, media-type) pairs enables us to abstract such
complications away. 

David, thank you for raising the comment, and I would be grateful if you
would confirm that this provides an adequate resolution.

Best regards,

Michael Kay

Changed status to "announced"

> David, thank you for raising the comment, and I would be grateful if you
> would confirm that this provides an adequate resolution.

Looks good to me, thanks,

David

qt-2003Dec0130-01: [XSLT2.0] fragment identifiers, media types and document()
http://lists.w3.org/Archives/Member/member-query-specs/2004Jun/att-0006/issues.html#qt-2003Dec0130-01
There was a report that the doc function was changed to allow fragment identifiers
(this happened 25 May 2004, item 11, as a response to
F/O comment MS FO LC2 016).
.
DEFERRED until we see the text in F and O implementing this decision.
      

xsl:is-schema-aware, xsl:supports-serialization and
xsl:supports-backwards-compatibility all return "yes"/"no"
would it be easier/more consistent (wrt casting to boolean)
if they returned "true"/"false" ?

David


    

Thanks for the comment. 

I don't have any strong views on this.

Michael Kay

Discussion at XSL F2F in Tampa


MK: We previously decided to make system-property always return
    strings so that the type of the result was precitable.  Would
    rather not undo that decision for these cases.
    

            
    
Decided not to make this change. Although true/false can be cast to a boolean, taking the EBV would give
the wrong answer, so there is no benefit: using the value directly as a boolean would give the
wrong anwer. The values yes/no are widely used already in XSLT.
         

            
    
*Action NW:  Respond rejecting proposal and giving rationale for current
              behaviour
	      
	      
*MHK announced decision on 1 Mar 2004
         

Re: issue qt-2003Dec0166-01

In message
http://lists.w3.org/Archives/Public/public-qt-comments/2003Dec/0168.html

David Carlisle suggested changing the values returned by certain system
properties from "yes" and "no" to "true" and "false".

The XSL WG discussed this and decided that the proposed change would be
undesirable, because the effective Boolean value of the string "false" is
true (as in XPath 1.0). So a user writing <xsl:if
test="system-property('xsl:is-schema-aware')"> would always go down the
"true" path.

David, I would be grateful if you could confirm that this is OK.

Regards,

Michael Kay

>David, I would be grateful if you could confirm that this is OK.

Yes, fine it was just a suggestion that occurred to me while reading the
draft and I thought might be worth raising. I wasn't sure myself that it
would necessarily be an improvement.

David

While I'm happy to see that schema support is not mandatory in XSLT, I'm
a little concerned that it appears impossible to write a stylesheet for
a schema aware processor that falls back gracefully on a basic one.

XSLT has always had quite good support for forwards and backwards
compatible behaviour and run-time testing for (and avoidance
of) non-implemented extensions.

However


  [ERR XT1660] A basic XSLT processor must signal a static error if the
  stylesheet includes an [xsl:]type attribute, or an [xsl:]validation or
  default-validation attribute with a value other than strip. 

seems to mean that I can't go

<xsl:when test="system-property('xsl:is-schema-aware')">
... xsl:validation ...
<xsl:otherwise>
  ... just relax ....



Wouldn't it be possible for a basic processor to simply ignore
schema-import and then have run time rather than static errors if any
schema specific features are encountered?

David

            
ACTION ITEM: MK will produce a proposal on this covering related areas as well. 
             Add a "guard" attribute to xsl:if and xsl:when.
         

In Tampa we discussed various ideas for handling compile-time
conditional code so that users could, for example, write a stylesheet
that would work both with schema-aware and non-schema-aware stylesheets.
We also wanted to improve on the situation where calls to non-existent
functions cannot be reported as a static error.

Specifically, we looked at (a) defining the concept of a constant
expression (an XPath expression capable of being evaluated at compile
time), and (b) defining a variant of xsl:if and xsl:choose that used a
constant expression as the test, allowing code within unused branches of
the conditional to be ignored, even if it contains things that would
otherwise be static errors.

In looking at this more closely, I think it would be a mistake to
confine this facility to contexts where an instruction is expected. I
think it is even more useful to conditionally include or exclude
top-level declarations, for example templates, functions, import-schema
declarations, or xsl:include declarations.

(PART A)

Therefore, I propose that we define a new standard attribute,
provisionally named [xsl:]use-when, which can be used on any element in
the stylesheet. Its value is a compile-time expression that evaluates as
a boolean, and its effect is that the element on which it appears,
together with all descendant elements and their attributes, are ignored
if the EBV is false. "Are ignored" means that no static errors are
reported in respect of such elements, and the result of the stylesheet
is the same as if the element was not there. (Yes, it's an "as if"
rule). XML-level rules, of course, continue to apply: for example the
ignored section must be well-formed and namespace-well-formed. If an
error occurs evaluating the constant expression, the stylesheet fails
with a static error.

For example:

<xsl:include href="xxx.xsl"
use-when="system-property('xsl:vendor')='xalan')"/>
<xsl:include href="yyy.xsl"
use-when="system-property('xsl:vendor')!='xalan')"/>

<xsl:import-schema namespace="xyz"
use-when="system-property('xsl:schema-aware')='yes'"/>

<xsl:message use-when="system-property('saxon:debug')='yes'">I woz
here!</xsl:message>

For simplicity, there is no if-then-else: if you have several
alternatives, you just have to invert the conditions: use-when="X",
use-when="not(X)".

(PART B)

What exactly is a constant expression? We discussed two possible ways of
defining it, an "additive" way (define what's allowed) and a
"subtractive" way (define what isn't allowed). On reflection, I think
there is a much cleaner approach: do it by defining a minimal context.
Specifically, a constant expression is any XPath expression you like,
with the following context:

In the static context:
XPath 1.0 compatibility = as usual (based on version)
In scope namespaces, default element namespace, default function
namespace = as usual
In scope schema definitions = predefined types only
In scope variables = empty
In scope functions = core XPath functions only, plus system-property,
element-available, and function-available, and constructors for
predefined types (no XSLT functions)
In scope collations, default collation = implementation defined
Base URI = as usual
Statically known documents = empty
Statically known collections = empty

In the dynamic context:
Context item, position, size = undefined (null)
Dynamic variables = empty
Function implementations = the functions in the static context
Current date/time, implicit timezone = implementation defined
Available documents and collections = empty

The fact that the context item is null in effect rules out a great deal
of the XPath language, notably path expressions. With no path
expressions and no variables and no external documents, the expression
is left to consist of core XPath functions and operators together with
literals and constructors for predefined types. The fact that we don't
allow XSLT functions rules out any reference to keys, decimal formats,
etc: there can be no reference to any other object in the stylesheet.

(PART C)

We change the rule that a reference to an unknown function is a dynamic
error. It is now a static error, except in backwards compatible mode or
in forwards compatible mode (in forwards compatible mode, all static
errors become dynamic errors, and this proposal doesn't change this).

(PART D)

We change the definition of function-available() so that it does not
test for stylesheet functions (only for functions defined externally to
the stylesheet). The reason for this is to ensure that
function-available() can be evaluated in a context-free way while the
stylesheet is being parsed: this means it cannot be allowed to have a
dependency on later parts of the stylesheet, or on things pulled in via
import/include.

This also allows constructs such as:

<xsl:function name="exslt:sqrt"
use-when="not(function-available('exslt:sqrt'))">

This makes the existing attribute override="yes|no" redundant.

(PART E)

What other requirements are there for a "switch"?

We have discussed in the past the need for a "process as if untyped"
switch. We decided against this in Bangkok because of the inability to
undo expansion of attribute and element defaults. But we have again been
leaning towards this in response to public comments.

Possible candidates here are:

(E1) a top-level xsl:assert, for example:

<xsl:assert test="system-property('xsl:schema-aware')='yes'"
            message="This stylesheet requires a schema-aware
processor"/>

<xsl:assert test="/* instance of element(invoice)"
            message="The input document must be a validated invoice"/>

<xsl:assert test="/* instance of element(*, xdt:untyped)"
            message="This stylesheet is designed to handle untyped
data"/>


(E2) an <xsl:input> declaration to control what happens to source
documents as they are input. (Logically strip-space and preserve-space
belong with this.) For example:

<xsl:input
    validation="strict|lax|preserve|strip"
    type="invoice"
    strip-comments="no"
    strip-space="*"
    expand-xinclude="yes"/>

The effect of "treat as untyped" would be achieved by writing
validation="strip". These options are basically parameters used to
control the input pipeline, in the same way as xsl:output supplies
parameters to control the output pipeline.

(PART F)

Having invented the concept of constant expressions, there are other
ways we could use it.

For example we could allow many attributes that currently have fixed
values (e.g. attributes of xsl:output, include/href, import/href,
validation and type, call-template/name, apply-templates/mode) to have
values that are "constant AVTs", i.e. attribute value templates
containing constant expressions only. This would make it easier to write
code to run in multiple configurations, but I think it could also be
very confusing.


I put these ideas forwards for discussion.


Michael Kay 

POSTSCRIPT: the "use-when" facility was adopted after further amendment and discussion
and incorporated into the specification. The further progress of the proposal was not tracked
under this issue heading. - MHK 2005-03-24


      </message>
   </issue>
   <issue id="qt-2004Jan0000-01" type="question" document="xslt20" completed="yes" disposition="accepted-clarification">
      <title>[XSLT 2.0] Extension functions with side-effects and optimizations</title>
      <message href="http://lists.w3.org/Archives/Public/public-qt-comments/2004Jan/0000.html" impact="raised">
         <from email="y2kmvs@us.ibm.com">Kenneth Stephen y2kmvs@us.ibm.com</from>
         <subject>[XSLT 2.0] Extension functions with side-effects and optimizations</subject>
         <date>2004-01-02</date>
         <body><![CDATA[

On the topic of extension functions with side-effects, the spec states :

"There is no prohibition on calling extension functions that have
side-effects (for example, an extension function that writes data to a
file). However, the order of execution of XSLT instructions is not defined
in this specification, so the effects of such functions are unpredictable."

      An extension function with side-effects can also be utilized in other
ways. For example, a global variable can be defined as a child of the
xsl:stylesheet element and the "select" can invoke the extension function.
The side-effect in question could be something like the creation of a file
indicating that XSLT processing has been done on something else. One of the
major XSLT (1.0) processors around optimizes such global variables away if
the value of the variable isnt being used for anything. I had some
correspondance with one of its maintainer recently, and this is what he had
to say on the topic :

"That's sorta the nature of the beast, I'm afraid. XSLT is a functional
language, and that means that stuff can get executed out-of-sequence or
optimized away... and that's only going to become more common as we
continue to work on improving stylesheet efficiency. Extensions with
side-effects are problematic at best; they really should be thought of as
extension Functions in the pure sense of the term.

The only way to force evaluation of a variable is to use that variable's
value. There are a few kluges that folks have come up with to use it and
throw it away, but it can be tricky to find one that is guaranteed not to
be optimized out in the future."

      This is a situation that doesnt seem to be explicitly addressed in
the 2.0 spec. While out of order execution of extension functions may be
kosher, is it ok to completely optimize away the variable itself?

Thanks,
Kenneth Stephen

T/L 793-6462
(512)823-6462

Thanks for the comment. The working group will consider this, but meanwhile
here is a quick personal response from me.
 
I think it would be a good idea for us to strengthen the warning that
extension functions with side-effects are a bad idea, and that it is not
only unpredictable when they will be called, but whether they will be called
at all, and if so, how often. We should advise that it is not generally
possible for XSLT implementors to determine whether or not an extension
function has side-effects, and that the burden therefore falls squarely on
stylesheet authors. We should advise implementors either (a) to tell their
users not to use extension functions with side-effects at all, or (b) to
document clearly under what conditions such functions can safely be used, or
(c) to provide extensions (e.g. extension instructions) that enable the
evaluation of such functions to be controlled.
 
In the end, though, I don't think we can change the situation that (a) we
can't disallow such functions, and (b) we can't precisely define their
effect.
 
Michael Kay

            
(MHK:)
            
Rewrite the first Note in section 18.1.2, which currently reads:
            
There is no prohibition on calling extension 
functions that have side-effects (for example, 
an extension function that writes data to a file). 
However, the order of execution of XSLT instructions 
is not defined in this specification, 
so the effects of such functions are unpredictable.
            
So that it instead reads:
            
In general, it is not possible for an implementation
to detect whether or not an extension function has side-effects.
This specification does not therefore state that such extension
functions are disallowed. However, because the order of execution
of XSLT instructions is undefined, extension functions with side-effects
are likely to have unpredictable results. In the general case it is not possible to
tell how often a particular function will be called, or what the sequence of calls will be.
            
Implementations may, of course, provide mechanisms (for example, extension
attributes) that allow additional control over such functions.
         

            
**Action MK:  Respond confirm MK's earlier provisional response.
              And strengthen wording in spec.
         

Kenneth Stephen raised this comment {qt-2004Jan0000-01} at

http://lists.w3.org/Archives/Public/public-qt-comments/2004Jan/0000.html

I made a personal response at:

http://lists.w3.org/Archives/Public/public-qt-comments/2004Jan/0003.html

The XSL Working Group considered the comment on 2004-01-20 and decided
to endorse my personal response. This recommends that we make no change
to the language specification, but strengthen the warning to
implementors and users of the dangers of allowing extension functions
that have side-effects.

Kenneth, can you please confirm that this action is sufficient to
resolve the comment?

Thank you for taking the time to comment on the specification.

Regards,

Michael Kay

Changed status to "announced"

      This is in response to
http://lists.w3.org/Archives/Public/public-qt-comments/2004Jan/0349.html .
Thank you for your response. This is entirely satisfactory. My apologies
for the delay in responding - I am not subscribed to the list and this was
the first I had checked it in a while.

Thanks,
Kenneth

I am writing to raise some concerns about two interrelated issues:

1. Backwards Compatibility Mode is used too liberally to mask unnecessary
changes in behavior.  Familiar elements and constructs ought to do the same
thing in XSLT 1.0 and 2.0 to the fullest extent possible.

2. In a related vein, the new behavior causes hidden performance penalties.

----------------------------------------------------------------------------
1. Backwards Compatibility

An example of these concerns is xsl:value-of; I have not yet read the spec
completely, but I am sure that there are more.

In the case of value-of, the default behavior for a 2.0 processor is to output
the concatenated string value of all elements of the sequence (possibly with
a separator).  If, however, the element is in backwards compatibility mode,
the 1.0 semantics of only outputting the first node are used.

I think this is bad for two reasons: it's inconsistent with 1.0, 
and it's a likely speed hit (see section 2).

Changing the value of the version attribute should not cause the elements 
on the stylesheet to start doing completely different things.  I think it
will cause undue confusion for new users of XSLT 2.0.  I could understand
making the change if this were an area of the spec widely criticized 
(RTFs), but for something like value-of the current behavior seems perfectly
adequate.

I suspect that the reason this change was made is that xsl:value-of can now
take XSLT children that form a sequence constructor.  That raises the
question, I assume, of what to do with this:

	<xsl:value-of>
		<a>hi</a>
		<b>ho</b>
	</xsl:value-of>

as currently defined, this will produce "hi ho".  Using the 1.0 "take the
first item" rule, this would produce "hi".  Clearly the former is more natural,
though it's not what I would expect (which is "hiho").  

I see a number of ways to solve this.  Perhaps have the lack of a separator
attribute mean that only the first item is used; this makes the Sequence
Constructor case output "hi" not "hi ho", so one could say that the separator
in Sequence Constructor cases defaults to " ".  Now everything works as
expected: using select preserves the old behavior, using the sequence
constructor still outputs all the items constructed, not just the first one.

This makes the code mildly inconsistent between the two syntaxes, but I think
that's okay.  People wouldn't write XSLT instructions they don't want executed,
but they often write xpath expressions that could potentially select more nodes
than they want.  This gets in to my optimization concerns below; furthermore,
it preserves backwards compatibility.

Another option is to create an <xsl:join separator=" "> and get rid of the
separator attributes on everything else.  This means the above example
would only output "hi", but you could easily get it to output "hi ho".
This would be consistent between the xpath and xslt and would simplify the
spec because the commands for joining things would only be located in one
place instead of being present on many different elements.

Using the Backwards Compatibility Mode to relax type restrictions makes
sense.  Using it to select between two different behaviors for
a given element seems excessive, particularly when it egregiously breaks
backwards compatibility.

----------------------------------------------------------------------------
2. Speed

Furthermore: the new value-of carries a hidden performance penalty.  If the
select expression refers to exactly one node, as is commonly the case, the
new definition will require iterating over all nodes that might match the
expression, rather than stopping at the first match.  In the above example,
"a/b", an XSLT processor used to be able to stop at the first "b" node, but
now must continue searching.  I am sure that there are other places where
the entire sequence is used that used to use only the first item, though I
have not combed the spec enough to know.

I think that changing rules that used to take only the first node so that they
now select multiple nodes will result in "gotcha!" performance penalties for
longtime users.  Writing XSLT that executes efficiently is hard enough without
the language changing the rules under your feet.



Thank you for your time and consideration.  

Niko Matsakis
DataPower Technology


    

Original MHK response:

Thanks for the comment. We will discuss this in the working group.

We tried to find the right balance here between doing what users new to
XSLT 2.0 would expect as the natural behavior, and retaining backwards
compatibility with 1.0. There are arguments both ways, and no obviously
right answer. 

One of the factors that comes into play is that it's fairly natural in
2.0 to use xsl:value-of to generate the value of a list-valued element
or attribute, supplying a sequence (say of integers) as the input. It's
true that we could require the "separator" attribute to get this
behavior, but many of us felt that this should be the default.

Regards,

Michael Kay

Discussion at XSL F2F in Tampa, 2004-01-20

   
Summary: No conclusion.  Needs further consideration and discussion.

            
 
Action SB:  write a proposal. On agenda for Feb 12th telcon.
MHK note: SB did this, dated around Feb 19.
         

Long discussion of first-item semantics.
DECIDED: retain the status quo.  [ANON] asks that the minutes show that he
still thinks the status quo is a bad idea.
ACTION: Michael Kay to respond to DataPower.

** done - MHK - see below
      

Our ref: qt-2004Jan0010-01

Niko,

Sorry for the long delay in responding to this message; this is because the
working group debated the issue several times before coming to a conclusion,
as we recognize the serious implications of the decision.

In the end, having considered various alternatives, we decided to confirm
the status quo as defined in the November 2003 working draft. There were a
number of factors:

* we felt that by default, xsl:value-of and attribute value templates should
produce the same result. In attribute value templates, we do not have the
luxury of a "separator" attribute to switch the behavior.

* in the case where the argument evaluates to a single node and the typed
value of that node is a sequence, we feel that producing the space-separated
atomized value as the result is the right thing to do; it's the effect that
achieves the best compatibility between schema-aware and non-schema aware
processors, and it is also consistent with what XQuery does.

* treating a sequence of several nodes each containing one atomic value
differently from a single node containing a sequence of atomic values would
be messily different from the way other constructs in the language behave.

* the backwards compatibility problem is manageable. There will be some
cases where users have to take action, for example where they have written
<xsl:value-of select="following-sibling::*"/>, but it will be fairly evident
in these cases what has gone wrong, and the fix, of inserting the predicate
[1], is not difficult. It is also not difficult for tools to assist in this.

* the potential for performance problems with constructs like <xsl:value-of
select="//title"/> is real, but it is no different from any other situation
where first item semantics have been changed (usually to an error). We think
that vendors will be able to find strategies to tackle this problem, either
by static optimization techniques, or by transition tools and services.

The arguments here are finely balanced but we feel that we have a better
language design for the future by this decision, and that this outweighs the
transition problems that the decision will cause.

Thanks for raising this important question, and feel free to respond if you
feel we have not addressed your concerns adequately.

Regards,

Michael Kay
for the XSL Working Group

http://www.w3.org/TR/2003/WD-xslt20-20031112/#namespace-fixup

The 5th bullet talks about element or attributes that are annotated
with the type xs:QName. It is not clear what happens in a conflict
situation.

Example:
<doc>
  <foo xmlns:bar="urn:bar1" att1="bar:something" />
  <foo xmlns:bar="urn:bar2" att2="bar:something" />
</doc>

att1 and att2 should be annotated as mentioned above.

<xsl:template match="doc">
  <xsl:copy>
    <xsl:copy-of select="foo/@*" />
  </xsl:copy>
</xsl:template> 

The bar prefix is used for two different namespaces.
Should the namespace fixup process change the value of the attributes
(by choosing unique prefixes)?

Regards,
Oliver Becker


/-------------------------------------------------------------------\
|  ob|do        Dipl.Inf. Oliver Becker                             |
|  --+--        E-Mail: obecker@informatik.hu-berlin.de             |
|  op|qo        WWW:    http://www.informatik.hu-berlin.de/~obecker |
\-------------------------------------------------------------------/

    

            

**Action MK: Clarify the text in 5.6.3.
**Action MK: Numbered list at end of 19.2.1 addresses how validation
             of elements is handled, but it doesn't handle free-
             standing attribute nodes.  Address as suggested by HT
             above.

         

qt-2004Jan0008-01: [XSLT2.0] OB04, 5.6.3 Namespace Fixup, QNames in content
ttp://lists.w3.org/Archives/Member/member-query-specs/2004Jun/att-0006/issues.html#qt-2004Jan0008-01
Discussed.  We're awaiting joint discussion of triples with Queries.
Michael needs to do clarification; his action still pending.
DEFERRED pending joint dicussion of triples.

==============================================================
EXTRACT FROM MINUTES OF 15 JULY 2004

Decided to make it an error.

(Status on 13 Aug 2004: MHK needs to check that this decision 
is reflected in the draft document
and that the decision is communicated to the originator)
==============================================================

==============================================================
MHK responded to originator on public-qt-comments, 20 AUG 2004
Spec updated, issue now completed.
==============================================================

      

    
 
2. Text nodes
-------------
It was not obvious to me how to generate text-nodes. Of the text comes from a parameter, <xsl:text> does not do it.
Thanks to Michael Kay I know now how to do it:
<xsl:function name="my:text" as="node()?">
    <xsl:param name="text" as="xs:string"/>
    <xsl:sequence>
        <xsl:value-of select="$text"/>
    </xsl:sequence>
</xsl:function>
Note that if $text is empty, no node will be returned!
But I wonder why it is not possible to create text nodes with <xsl:text> as freely as you create attribute nodes with <xsl:attribute> and element nodes with <xsl:element> and namespace nodes with <xsl:namespace>.

[MHK response]

I think the XSL WG should look again at whether we can make <xsl:text>
and <xsl:value-of> synonymous. The current nomenclature will, as you
point out, cause people to expect that the instruction for creating text
nodes is <xsl:text> rather than <xsl:value-of>, and we should see if we
can meet that expectation while retaining backwards compatibility.

POSTCRIPT (MHK, 2005-03-23)

The only subsequent action recorded is that the WG rejected the proposal, the issues list does not give a specific
reference to the minutes of the decision or the messages announcing the decision. 

In fact, the comment was raised in the form of a question rather than a proposal, so the disposition of
"rejected" is probably inappropriate. 

The suggestion to make xsl:text and xsl:value-of synonymous was debated and found impractical. However,
the WG did subsequently (in the Edinburgh meeting) devise changes to the behaviour of xsl:value-of that
alleviate some of the usability problems.

    

In the MIME type registration appendix, replace the reference to RFC
1738, Section 6 with a reference to RFC 2396, Section 7.

                                        Be seeing you,
                                          norm

    

            
Thanks for the comment. I have corrected the reference so it now points to the more recent RFC.

I trust this meets with your approval.
         

Changed status to "announced"

Completely.

                                        Be seeing you,
                                          norm
                                          

SUGGESTION
13.1.3 Sorting using Collations
"The lang and case-order attributes are ignored if a collation
attribute is present"
Problem:
 It looks like there is an implicit assumption that lang and case-order
 attributes functionality could be provided by collation.   A lang and
case-order attributes functionality looks like a subset of collation
functionality. If it is not the case, then
a user cannot have functionality where e.g.  there is case-order and
 some collation parameters other than parameters corresponding  lang.
Solution:
Specify explicitly in description of collation that collation should
provide with
lang and case-order functionality.


Igor Hersht
XSLT Development
IBM Canada Ltd., 8200 Warden Avenue, Markham, Ontario L6G 1C7
Office D2-260, Phone (905)413-3240 ; FAX  (905)413-4839

    

            
I believe the description of collations in the Functions and Operators specification
 makes it clear that a collation, as identified by a URI, is fully defined: that is,
  once you have specified a collation, you have specified all possible tailoring, 
  and you don't need to specify any further parameters. 
            
From F+O 7.3.1:
            
"Some collations, especially those based on the [Unicode Collation Algorithm]
 can be "tailored" for various purposes. This document does not discuss such
  tailoring, nor does it provide a mechanism to perform tailoring. Instead,
   it assumes that the collation argument to the various functions below
    is a tailored and named collation. "
            
So you are right, but I think the assumption is explicit rather than implicit.
            
We did at one stage have an essay on collations in the XSLT spec, 
but we took it out in favour of linking to the similar essay in the F+O specification.
            
Do you think we need to do any more, or can we close this with no action?
            
Regards,
            
Michael Kay 
         

Issue: qt-2004Jan0021-01

Originally raised at:
http://lists.w3.org/Archives/Public/public-qt-comments/2004Jan/0021.html

The Working Group reviewed this comment on 26 Feb 2004 and agreed that it
would be useful to further clarify the fact that the "collation" identified
by a collation URI is already a fully tailored collation, and that this is
why the case-order and lang attributes are only meaningful if no collation
URI is specified. I intend to include similar wording to that already
present in section 7.3.1 of F+O. Specifically, after the cross-reference to
F+O, to add text to the effect:

"Some specifications, for example the [Unicode
<http://www.w3.org/TR/xpath-functions/#Unicode-Collations#Unicode-Collations
>  Collation Algorithm], use the term "collation" to describe rules that can
be tailored or parameterized for various purposes. In this specification, a
collation URI refers to a collation in which all such parameters have
already been fixed. Therefore, if a collation URI is specified, other
attributes such as case-order and lang are ignored."

I would be grateful if you could confirm that this resolution of your
comment is acceptable.

Michael Kay
For the XSL Working Group

SUGGESTION 1:
3.10.3 Stylesheet Import.
...
"The order of import precedence (lowest first) is D, B, E, C, A.

In general, a declaration with higher import precedence takes precedence
over a declaration with lower import precedence. This is defined in detail for
each kind of declaration"

It is not clear for me why "In general". Why we cannot have it
as a common rule.I don't understand why sometimes we use import
precedence (e.g. in 9.5 Global Variables and Parameters) sometimes
don't (e.g. in 16.4.1 Defining a Decimal Format). I think it should
be explained. If there is no any technical reason to have it just "In
general" ,
we should have common rules - we should use import precedence
(not using import precedence as a "common rule" makes no sense because it
would
have the same functionality as xsl:include).

Personal response: I've struggled with these inconsistencies for a while. 
We're limited in what we can do about them because of backwards compatibility.

I think we could possibly reduce it to two categories: 

(a) highest precedence wins. This applies to templates, variables, params, strip-space,
 namespace-alias, import-schema. We have already aligned the rules for how conflicts
  are dealt with. For named objects a conflict is a static error, for rules
   (templates, strip-space) it's a dynamic error.

(b) merge all definitions. This applies to keys, attribute sets, decimal formats,
 output definitions. Currently each of these behaves a bit differently. With 
 keys there are never any conflicts. With attribute sets each attribute 
 is subject to import precedence. With output definitions each output property 
 is subject to import precedence. Decimal formats do stand out as the exception, 
 and I can't see a good reason why they shouldn't be aligned with xsl:output, 
 using the import precedence of each property separately rather than making 
 conflicting definitions an error.

Michael Kay

 
Spirit of comment accepted and we will try to achieve it, naturally with the constraint of 
 backward compatibility. Decimal format is the main "oddity".

We need a specific proposal. Action Mike Kay.
     
      

Re: qt-2004Jan0019-01: [XSLT2.0] Consistent Rules on Import Precedence 
[XSLT2.0] Consistent Rules on Import Precedence, Igor Hersht
igorh@ca.ibm.com (2004-01-11) 

SUGGESTION 1:
3.10.3 Stylesheet Import.
...
"The order of import precedence (lowest first) is D, B, E, C, A.

In general, a declaration with higher import precedence takes precedence
over a declaration with lower import precedence. This is defined in detail
for
each kind of declaration"

It is not clear for me why "In general". Why we cannot have it
as a common rule.I don't understand why sometimes we use import
precedence (e.g. in 9.5 Global Variables and Parameters) sometimes
don't (e.g. in 16.4.1 Defining a Decimal Format). ...


The XSL WG discussed this comment and I was actioned to propose measures
that would tidy up the rules.

I think we have 5 different algorithms:

Algorithm 1: named objects

I believe that we have now achieved consistency for "named objects" where
only one object is applicable (global variables, stylesheet functions, named
templates, imported schemas, character maps, namespace aliases). The rule
here is always that the highest precedence wins, and an error occurs if two
objects have the same precedence and there is no object with higher
precedence.

Algorithm 2: rules

This applies to template rules and to strip-space/preserve-space
declarations. The difference from rule 1 is that if two definitions have the
same precedence, the conflict is resolved using priority.

Algorithm 3: merge definitions

For attribute sets and output definitions we merge multiple definitions.
Conceptually we take these elements as declaring one object for each
"attribute", and apply algorithm 1 at the level of individual attributes.
However these two cases aren't completely consistent because attribute sets
expand recursively.

Algorithm 4: definitions are additive

This rule is applied to xsl:key.

Algorithm 5: no conflicts allowed

This rule is applied to xsl:decimal-format


The most obvious tidying up we can do is to remove algorithm 5, and handle
xsl:decimal-format under algorithm 3. The rules would then be the same as
xsl:output: for each individual attribute, the explicit (non-default) value
of that attribute with highest import precedence is used. This change would
be backwards compatible, since currently any conflict is an error.

Algorithm 4 also seems anomalous. However, it would be difficult to make it
fit any of the other rules precisely, and any such change would be backwards
incompatible.

I don't see any other obvious potential for improving the situation, beyond
the change to xsl:decimal-format. We could try and explain the rationale
more clearly, but I don't think that a spec needs to be an apologia.

Michael Kay

*** STATUS minuted at 2004-03-18 telcon:

Spirit of comment accepted and we will try to achieve it, naturally
with the constraint of backward compatibility. Decimal format is
the main "oddity".
 
We need a specific proposal. Action Mike Kay.
Status: proposal written:
http://lists.w3.org/Archives/Public/public-qt-comments/2004Mar/0207.html

        NEW STATUS: Has come to the conclusion that the only thing we can 
do is Decimal Format.  Action should be closed (but issue is still open).

Proposal to change decimal format to follow xsl:output rules.
(currently it is an error to have multiple definitions).

Proposal accepted.

Action Mike Kay to send response.

** RESPONDED 2004-04-28

** SPEC UPDATED - MHK

---

Note: there is also a comment on the Mulberry list asking for an explicit
specification of "default value" (useful when overriding stylesheets).
One notable example is to "unset" the doctype (could be solved by
eg by setting it to "").

Action Henry Z to follow up.
   

SUGGESTION 2:

lang attribute used in xsl:number(12 Numbering)
and xsl:sort (13.1 The xsl:sort Element) language argument used in
date formatting functions (16.5 Formatting Dates and Times)
format-dateTime, format-date, format-time
The attribute and arguments have common rules "The effective
value of the attribute must be a value that would be valid for
the xml:lang attribute"
(http://www.w3.org/TR/1998/REC-xml-19980210#sec-lang-tag).
The specs define precisely mapping from value of the attribute to ISO 639
language
and ISO 3166 country codes.

Problem Mapping from a value of the attribute to a variant code is not
specified.

 Solution
A variant code should be constructed from the substring after the second
tag separator
by converting the substring to upper case and replacing all '-' characters
with '_'.
The variant code is ignored, if implementation cannot find a resources for
the variant code
with given ISO-639 language and ISO-3166 country code. A warning message
should be issued
in this case. Changes in behavior caused by the variant are implementation
defined.

Personal response: 

I may have misunderstood the intent behind the specification of xml:lang, 
but my reading of it is that subcodes after the first can be anything you like, 
so long as it is alphabetic: for example, they can be used for variants.

I'm reluctant to fall out of line with the XML specification here.

I'm also rather dubious of having too many of these mechanisms where we specify 
the syntax but say nothing about the semantics. Does it really improve interoperability?

*** STATUS minuted at telcon on 2004-03-18: 

        Comment to be clarified - Action Henry Z.
        NEW STATUS: Henry still has this on his list, will send email.

Hello,

     I discussed with Igor Hersht his comment qt-2004Jan0019-02 [1]:  "
[XSLT2.0] Consistent rules for lang attribute."  From that discussion, I 
understand that his concern was that in many (most?) real-world APIs for 
localization, locales are divided into three parts:  a language code, a 
country or region code and a variant.  On the other hand, documents such 
as [2,3] specify no fixed meaning for subtags after the region.

     I believe Igor was hoping that something slightly more explicit could 
be stated about the subtags after the language and region, to guide both 
implementers and users.

Thanks,

Henry

   Henry Z had posted clarification - asking for more detailed semantics.
(http://lists.w3.org/Archives/Member/w3c-xsl-wg/2004Mar/0040.html)

It seems more appropriate for the RFCs to specify any such semantics.

Action Henry Z to draft response rejecting comment.

   
   

SUGGESTION 3:
16.4.1 Defining a Decimal Format

Add attribute lang? = { nmtoken }.
The rules for the attributes are the same as for
this attributes in other elements (e.g. xsl:number).
lang attribute should control default values for attributes:
decimal-separator, grouping-separator, infinity minus-sign, NaN,
percent, per-mille, zero-digit.
(e.g. text "decimal-separator specifies the character used for the
decimal-separator-sign;
the default value is the period character (.)"
should be replaced with
decimal-separator specifies the character used for the
decimal-separator-sign;
the default value is default for a given language".

 A personal response: I think this is of marginal benefit. I don't think it's difficult
 for users to specify exactly what formatting they want, and it gives better 
 interoperability if they do so: how likely is it that different processors 
 will choose the same representation for "NaN" in Italian?

Michael Kay

Agree. Not that important (but seems to be good).

Igor Hersht
XSLT Development
IBM Canada Ltd., 8200 Warden Avenue, Markham, Ontario L6G 1C7
Office D2-260, Phone (905)413-3240 ; FAX  (905)413-4839

qt-2004Jan0019-03 : [XSLT2.0] Add lang attribute to xsl:decimal-format

This relates to "Suggestion 3" in
http://lists.w3.org/Archives/Public/public-qt-comments/2004Jan/0019.html

The XSL Working Group reviewed this suggestion on 26 February. The group
felt that although it might be "nice to have", it was a feature that was not
essential to satisfy any known requirement or to fix a pressing problem, and
that we should therefore not include this feature in this version of the
specification.

I would be grateful if you could confirm that you can live with this
decision.

Many thanks for making the comment,

Michael Kay
For the XSL WG

SUGGESTION 4:
20 Serialization normalize-unicode?  attribute of the xsl:output element
Problem:
Not clear which normalization forms to use. "NFC"?
Why we should have "NFC" only, if we can support others as in
fn:normalize-unicode?

Solution:
normalize-unicode? = string
The attribute should follow the rules of the second
argument($normalizationForm   )
of the fn:normalize-unicode
(http://www.w3.org/TR/xquery-operators/#func-normalize-unicode)


Igor Hersht
XSLT Development
IBM Canada Ltd., 8200 Warden Avenue, Markham, Ontario L6G 1C7
Office D2-260, Phone (905)413-3240 ; FAX  (905)413-4839

Action on issue qt-2004Jan0019-04 (henry Z)

http://lists.w3.org/Archives/Member/w3c-xsl-wg/2004Apr/0000.html

Summary: some discussion of whether the value should be a QName or an NMTOKEN.
Decided to leave it as an NMTOKEN

Hello,

     From the minutes of the 2004-03-25 XSL WG call [1]:

>>qt-2004Jan0019-04 : [XSLT2.0] Specify normalization form for 
serialization
>>==========================================================================
>>
>>
>>Decided to accept comment, provided that it would not be inconsistent
>>with the XML Recommendation. Also impacts Serialization.
>>
>>Henry Z to draft text.
>>
>>        CURRENT STATUS: In France made decisions, will write up, then 
Mike
>>can
>>just apply the text.  - keep on Agenda to track -
>>http://lists.w3.org/Archives/Member/member-query-specs/2004Mar/att-0002/new-issues.html#qt-2004Jan0019-04
>
>Action on Henry Z continued.

     In [2], I described the changes to serialization we agreed to in 
Mandelieu.  Following are the changes to XSLT 2.0 required to synchronize 
with the changes to serialization.  These edits are with respect to the 
last call working draft of XSLT 2.0.[3]

------
In Section 20 and Appendix D, in syntax diagrams for xsl:output, change

<<
  normalize-unicode = "yes" | "no"
>>

to

<<
  normalization-form = "NFC" | "NFD" | "NKFC" | "NKFD" |
                       "fully-normalized" | "none" | nmtoken
>>

------
In Section 20, in the second bulleted list, replace the ninth bullet, 
which defines the normalize-unicode attribute, with the following:

<<
o The value of the normalization-form attribute provides the value of the 
normalization-form parameter to the serialization method.  A value that is 
an nmtoken, other than one of those enumerated for the normalization-form 
attribute, specifes an implementation-defined normalization form; the 
behavior in this case is not specified by this document.  The default 
value is none.
>>

------
In Appendix G, in definition of output element, replace definition of 
normalize-unicode with the following attribute declaration:

<<
   <xs:attribute name="normalization-form" type="xs:NMTOKEN"/>
>>

Thanks,

Henry
[1] http://lists.w3.org/Archives/Member/w3c-xsl-wg/2004Mar/0043.html
[2] 
http://lists.w3.org/Archives/Public/public-qt-comments/2004Mar/0276.html
[3] http://www.w3.org/TR/2003/WD-xslt20-20031112/
------------------------------------------------------------------
Henry Zongaro      Xalan development
IBM SWS Toronto Lab   T/L 969-6044;  Phone +1 905 413-6044
mailto:zongaro@ca.ibm.com


[*** CHANGES APPLIED - MHK]


         

            
 
Action MHK:  write a proposal.
         

I raised this initially on the XSL WG internal list at:

http://lists.w3.org/Archives/Member/w3c-xsl-wg/2004Jan/0006.html

The WG accepted the proposal with modifications, and actioned me to
raise it as a public comment to give visibility and invite comments.

The modified proposal is as follows:

We should have a rule that if a global variable, parameter,
template, or function declares its type, then it cannot be overridden in
an importing stylesheet except by an object whose type is compatible.

For example, if xmlspec.xsl declares

<xsl:param name="diff" select="false()" as="xs:boolean"/>

then it should not be possible for xsltspec.xsl (which imports
xmlspec.xsl) to declare

<xsl:variable name="diff" select="0"/>

Overriding a variable or parameter is really just another way of giving
it a value, and this ought to be a type-safe operation.

We propose to keep the rules very simple:

* if a stylesheet contains a global variable, parameter, function, or
template that declares the type of its value/result using an "as"
attribute, then any definition in an importing stylesheet that overrides
this definition must also declare a type, and this must be the same
type. 

* a function A that overrides a function B must use the same type
declarations in each of the function parameters

* a template A that overrides a template B must declare all the
parameters that B declares, with the same types; required parameters may
be made optional but optional parameters may not be made required;
additional parameters may be added but they must be optional.

Michael Kay

I took an action to produce a detailed proposal for this facility, which
we already agreed in principle.

Our decision in principle was that we should require the declared types
of an overriding variable, template, or function to be identical to the
declared type of what it is overriding.

I've taken a closer look at this, and have come to the conclusion that
the cure may be worse than the disease. Firstly, if the overriding
declaration is seriously incompatible with the declaration that it
overrides, then code that relies on the "old" type is going to fail with
a type error anyway. For example, if you override a date with an
integer, code that assumes it's a date will almost certainly fail.
Secondly, the constraint that the definitions must be identical seems to
prevent some perfectly reasonable things, like overriding the
declaration

<xsl:variable name="p">2</xsl:variable>

with

<xsl:param name="p" as="xs:integer"/>

(the declared type of the first definition is item()*).

Any rule that tries to be less crude than this is going to get very
complicated.

The main benefit of a rule preventing incompatible overrides would be to
move towards separate compilation (or at least separate type-checking)
of modules. But we're a long way from achieving that benefit, because
for example an imported module can rely on variables that are declared
only in the importing module.

So I propose to withdraw this proposal.

Michael Kay

Issue: qt-2004Jan0350-01

See:
http://lists.w3.org/Archives/Public/public-qt-comments/2004Jan/0350.html

This comment proposed the addition of rules requiring an overriding
definition of a variable, template, or function to declare a type consistent
with the type of the object being overridden.

For the record, this proposal has been withdrawn after WG review. On
examination, such rules proved too restrictive; and in cases where the type
is incompatible with the overridden object, this will usually result in a
type error being reported at the point where the object is referenced or
used.

Michael Kay

This is a request for a spec change related to the definition of the
xsl:output-character[1] element in section "20.1 Character Maps" of the
XSLT 2.0 last call Working Draft.

  [1] http://www.w3.org/TR/xslt20/#element-output-character

      <xsl:output-character
        character = char
        string = string />

  [2] http://www.w3.org/TR/xslt20/#character-maps

      Definition: A character map allows a specific character appearing
      in a text or attribute node in the result tree to be substituted
      by a specified string of characters during serialization.

In the definititon for the xsl:output-character element, either:

  A. Specify that the presence of any extra attributes in an
     xsl:output-character instance in addition to the required
     "character" and "string" attributes should not cause a compliant
     XSLT 2.0 processor to generate an error.

  or

  B. Add additional optional attributes to the definition, for the
     purpose of specifying:

       - the ISO character entity name; e.g., entity="Ccedil" 
       - the ISO character name; e.g., name="LATIN CAPITAL LETTER C WITH CEDILLA"

Rationale: Make character maps easier to read/maintain, and facilitate use
of character maps other than just the use described in the XSLT 2.0 spec.

For example, in a character map for substituting Unicode characters with
roff escape-sequence strings, an entry for the "capital C cedilla"
character would look like this:

  <xsl:output-character
    character="&#x00C7;"
    name="LATIN CAPITAL LETTER C WITH CEDILLA"
    entity="Ccedil"
    string="\(,C"/>

I don't think most users would want to try editing a character map
without such human-readable information in it.

[Summary of MHK response]

1. You can already use extension attributes

2. We're unlikely to add specific attributes if they are only for documentation

This comment from Michael Smith requested the addition of documentary
attributes to <xsl:output-character>

The Working Group reviewed the comment on 26 Feb 2004 and endorsed my
earlier unofficial response: there is a general mechanism for adding extra
documentary attributes to any XSLT element (in a user-defined namespace),
and the WG considers that this mechanism meets the stated requirement.

Thank you for raising the comment, Michael. Could you please confirm that
this resolution is acceptable?

Michael Kay

For the XSL WG

The resolution for this issue is acceptable. Thanks

  --Mike

Hello,

the new functionality for processing simple text using regular expressions
is very useful. However, I wonder why it is restricted to one expression
per instruction.

A more powerful instruction could allow multiple regular expressions that
will be processed in lex-like manner [1]. That means the regex attribute
would be a property of xsl:matching-substring and not of xsl:analyze-string.
Replacing multiple substrings with proper markup then would require less
nested XSLT elements. Having only one xsl:matching-substring in this new 
semantics would behave exactly like the current version. 

Moreover, I believe this model reflects the template model of XSLT for
text processing: xsl:analyze-string is a container like xsl:stylesheet,
xsl:matching-substring is the counterpart for xsl:template.

I would be great if this enhancement of xsl:analyze-string could be
considered for the final XSLT specification.

Best regards,
Oliver Becker


[1] M. E. Lesk and E. Schmidt: "Lex - A Lexical Analyzer Generator"
    e.g. http://dinosaur.compilertools.net/lex/index.html


/-------------------------------------------------------------------\
|  ob|do        Dipl.Inf. Oliver Becker                             |
|  --+--        E-Mail: obecker@informatik.hu-berlin.de             |
|  op|qo        WWW:    http://www.informatik.hu-berlin.de/~obecker |
\-------------------------------------------------------------------/

Further discussion:

Mike,

> I think the working group members would find it very much easier to
> assess the value of what you are proposing if you could provide some
> examples or use cases that show how the facility  would be used, ideally
> comparing the existing solution with the new solution.

Well, David Carlisle already provided a list a use cases in
http://lists.w3.org/Archives/Public/xsl-editors/2002JanMar/0083.html

I cite RE-4 and RE-7:
<citation>
RE-4: Multiple regexp-replace.
  The proposed replace function in F&O replaces substrings matching a
  single regexp but often one wants to replace many strings in parallel.

  I am assuming here that the normal XSLT creation model is followed that
  _all_ replacements take place (where possible, with a suitable priority
  mechanism for controlling clashes) on (substrings of) the original
  string, and a new node tree is constructed. Even when generating strings
  (as here) this differs from  the result of repeatedly calling the replace
  function proposed in the F&O draft as that would, most naturally, apply
  later regexp matching to the _result_ of earlier matches.

  An example recently mentioned on xml-dev:

RE-4a: Going from an XML unicode string to TeX:
    replace &     by \&
            $     by \$
            #169  by \copyright
            #233  by \'{e}
            <     by \lt
            #322 by \l
            ...
RE-4b: The reverse of this transformation.
</citation>

<citation>
RE-7: Transliteration
  Take an input string in AMS cyrillic transliteration scheme and convert
  to Unicode characters. The exact scheme will be omitted here but the
  details are available at http://www.tex.org.
  This differs from the "multiple regexp" example
  in the way conflicting regexp matches need to be handled. For multiple
  regexp matching above one needs a priority mechanism so that certain
  regexp are matched first and lower priority regexp are only applied to
  remaining strings. Transliteration matches need to be applied by
  matching the start of the input string with the longest possible match,
  replacing this by the transliterated sequence, and then finding he
  longest possible match at the start of the remaining string.
  Thus if abc transliterates to X and 
          bcd transliterates to Y
          xab                   Z
          c                     C
          d                     D
  then
    abcd  -> XD
    xabcd -> ZCD
  Thus you could not, for example, start by replacing all abc by X.
</citation>


A use case from my own work: create an HTML representation (verbatim
with syntax highlighting) for a given XML source. Without to discuss whether
this is the right way to do, I have to replace within the text content
  newlines by <br>
  spaces by #160
  < by &lt;
  & by &amp;
The current specification of xsl:analyze-string requires a nested
invocation like this:
<xsl:analyze-string select="." regex="\n">
  <xsl:matching-substring><br /></xsl:matching-substring>
  <xsl:non-matching-substring>
    <xsl:analyze-string select="." regex="' '">
      <xsl:matching-substring>&#160;</xsl:matching-substring>
      <xsl:non-matching-substring>
        <xsl:analyze-string select="." regex="[&lt;]">
          <xsl:matching-substring>&amp;&lt;</xsl:matching-substring>
          <xsl:non-matching-substring>
            <xsl:analyze-string select="." regex="[&amp;]">
              <xsl:matching-substring>&amp;&amp;</xsl:matching-substring>
              <xsl:non-matching-substring>
                <xsl:value-of select="." />
              </xsl:non-matching-substring>
            </xsl:analyze-string>
          </xsl:non-matching-substring>
        </xsl:analyze-string>
      </xsl:non-matching-substring>
    </xsl:analyze-string>
  </xsl:non-matching-substring>
</xsl:analyze-string>

(I don't use regular expression very often, so please excuse possible mistakes.)

The new proposal allows a shorter notation:
<xsl:analyze-string select=".">
  <xsl:matching-substring regex="\n"><br /></xsl:matching-substring>
  <xsl:matching-substring regex="' '">&#160;</xsl:matching-substring>
  <xsl:matching-substring regex="[&lt;]">&amp;&lt;</xsl:matching-substring>
  <xsl:matching-substring regex="[&amp;]">&amp;&amp;</xsl:matching-substring>
  <xsl:non-matching-substring>
    <xsl:value-of select="." />
  </xsl:non-matching-substring>
</xsl:analyze-string>

(It looks a little bit like choose/when/otherwise, but the semantics is
left-to-right matching with the longest possible initial string.
If there are two or more branches that would match the same longest
string then the first branch will be used, i.e. a priority is given
by the order of the matching-substring branches.)


Another use case: pretty printing of code examples for common programming
languages. Consider, someone writes a book about Java, C or whatever in
XML (say DocBook) and wants to include code examples (real code!).
The function unparsed-text() allows to access that code.
Now the author wants to print all keywords in bold font, all strings
italics etc ...
Currently this task seems to be very difficult to solve with the given
regular expression semantics (IMHO; Everybody is free to prove me wrong,
of course). Particularly it is difficult to distinguish keywords from
identifiers that contain keywords literally. The only practical solution
currently seems to preprocess that code before using XSLT.

Here's a fragment of a solution with the proposed semantics
<xsl:analyze-string select=".">
  <!-- keywords -->
  <xsl:matching-substring regex="if|while|for|do| ....">   <!-- etc -->
     <b><xsl:value-of select="." /></b>
  </xsl:matching-substring>
  <!-- strings (simplified) -->
  <xsl:matching-substring regex="'&quot;'([^&quot;]*)'&quot;'"> 
     <xsl:text>"</xsl:text>
     <i><xsl:value-of select="regex-group(1)" /></i>
     <xsl:text>"</xsl:text>
  </xsl:matching-substring>
  <!-- identifiers (might contain keywords as substrings) -->
  <xsl:matching-substring regex="[a-zA-Z_][a-zA-Z0-9_]*">
     <xsl:value-of select="." />
  </xsl:matching-substring>
  <!-- characters that need escaping: &lt; &amp; (not shown, see above)-->
     ....
  <!-- everything else -->
  <xsl:non-matching-substring>
     <xsl:value-of select="." />
  </xsl:non-matching-substring>
</xsl:analyze-string>

     
I hope these examples are convincing.
Best regards,
Oliver

Dave Pawson contribution at:
http://lists.w3.org/Archives/Public/public-qt-comments/2004Feb/0158.html


Speaking in support of Olivers proposal:
  With an xml to \tex recent case,

<xsl:function name="dp:escHash" as="xs:string">
  <xsl:param name="str" as="xs:string"/>
 

 <xsl:variable name="t0">
        <xsl:value-of select="if (contains($str,'{' ))
                              then replace($str, '\{', '{day}{of}') 
        else $str"/>
  </xsl:variable>
etc.


to achieve the objective of this proposal, multiple replacements
in the same string, I had 8 sequences of variable creation
based on the previous substitution.

Very messy.

Good proposal Oliver.

regards DaveP


Response from Oliver Becker at:
http://lists.w3.org/Archives/Public/public-qt-comments/2004Feb/0159.html

owever, why are doing it in this rather long-winded way?

<xsl:variable ..
   <xsl:value-of select= ..
   
can be written in your case as

<xsl:variable select= ..

Then: why are you testing for the occurance of the { character?
I think, simply calling the replace function (regardless whether
there is a substring to replace or not) will give you the same result.

<xsl:variable select="replace($str, '\{', '{day}{of}')" />

If you need 8 replacements then nested invocations of replace should
do it:

replace(replace(replace(....)
                ...
        '\{', '{day}{of}')

This is still a little bit messy, but probably shorter than using
xsl:analyze-string, even with my proposal.
xsl:analyze-string is useful for replacements with markup 
(aka complex content).

(Which means that in my last email one of my my use cases -- the XML
to HTML verbatim formatter -- is not a real use case, because most of
the replacements used only characters. However, the second example --
code syntax highlighting -- still stands.)

Regards,
Oliver

Summary of discussion: the feature looks powerful, but involves a lot of extra complexity.
Is the requirement real? The WG eventually decided that the requirement was not strong enough
to justify adding the feature. Action on MK to respond to Oliver.


** action completed: see 
http://lists.w3.org/Archives/Public/public-qt-comments/2004Apr/0020.html

I'm not sure if this has been reported or fixed already, but there is an error 
in the <xsl:namespace> example in the 12 November 2003 Working Draft of XSLT 
2.0. It has:

<xsl:namespace name="xs" select="http://www.w3.org/2001/XMLSchema"/>

Where it should be:

<xsl:namespace name="xs" select="'http://www.w3.org/2001/XMLSchema'"/>

-Erik

Thank you for pointing out this error.

I have corrected the example.

Michael Kay

Thanks, fixed

Tacitly acknowledged

This proposal updates a previous internal proposal:

http://lists.w3.org/Archives/Member/w3c-xsl-wg/2003Oct/0000.html

which got timed-out in the WG deliberations on more substantial matters.
It attempts to revise the way in which particular dynamic errors are
classified, to give a more consistent treatment. I have reviewed and
revised the originally proposed classifications.

The main aim of this proposal is to get rid of the interoperability
problems that arise because some processors treat a construct as an
error and others take the recovery action. Many of the errors previously
classified as recoverable errors are now classified as warning
conditions: for these conditions, the processor may (but is not required
to) output a warning, but must continue processing. So all processors
will produce the same result tree, though some may give warnings along
the way. Some other errors (those where no user would ever invoke the
recovery behavior deliberately) are changed to non-recoverable errors,
and a few are changed to non-errors, with the previous recovery action
becoming the norm.

There is a new (small) category of "system errors", which are conditions
that are outside the direct control of the stylesheet author or the XSLT
processor. The main characteristic of these errors is that the effect is
to some extent implementation-dependent.

Each error code is followed by a note describing the proposed change if
any, and then a copy of the existing error text.

Michael Kay

For detailed proposal see:

http://lists.w3.org/Archives/Public/public-qt-comments/2004Feb/0129.html

Summary: an inclusive discussion, resulting in a request to the proposer to revise and
resubmit the proposal.



** Proposal subsequently withdrawn by the proposer. Minuted on 2004-06-25.

POSTSCRIPT: The Working Group returned to this subject in the spring of 2005, and
agreed to reclassify many recoverable errors either as non-recoverable errors or as
"not an error" (that is, the previous recovery action became the normal, mandatory, action.)

The following comment was initially raised at:

http://lists.w3.org/Archives/Member/w3c-xsl-wg/2003Oct/0122.html
(member-only URL)

(I think this comment slipped off the radar because we were too busy
getting the Last Call draft published at the time. I have updated the
note slightly to address the relationship of serialization and
validation).

We have changed the rules for namespace fixup so that when an element C
is attached as a child of parent element P, it no longer automatically
inherits the namespace nodes of P.

We defined it this way for xsl:copy, and it works reasonably well in
that case. The idea is that if you put your XML payload in a SOAP envelope
and then extract it again, it hasn't been polluted with SOAP namespaces.
This leads occasionally to a superfluous xmlns="" undeclaration, but that's
liveable-with.

More problematic is the situation with xsl:element. In a formal sense
the rules here are exactly the same: we create a new element, in this case
with no namespace nodes of its own unless we use xsl:namespace to create
them. It then gets fixed up, which gives it namespace nodes for the element and
attribute names, and then it gets attached to a new parent, at which
point it acquires no additional namespace nodes.

The effect of this is that if you are writing a stylesheet, and do:

<xsl:template match="/">
  <xsl:element name="xsl:stylesheet" 
               namespace="http://www.w3.org/1999/XSL/Transform">
     <xsl:namespace name="xs">http://www.w3.org/2001/XMLSchema</xsl:namespace>
     <xsl:element name="xsl:template">
       <xsl:attribute name="match">attribute(*,xs:date)</xsl:attribute>
     </xsl:element>
  </xsl:element>
</xsl:template>

Then the "xs" namespace is in scope for the generated xsl:stylesheet
element, but not for the generated xsl:template element, which means
that the reference to xs:date is an error. At any rate, it will be an error
if you serialize with undeclare-namespaces="yes"; but possibly also if you
try to use the result tree as a stylesheet without serializing it, since the
parser will look for an in-scope namespace node to resolve "xs:date" and
won't find one. 

In a slightly modified example, one could show that QName-valued
attributes would not pass validation. But this actually shows up a gap in our
specs: we define validation formally in terms of a process of
serializing the tree, then parsing to create an Infoset, and then
validating the Infoset. But we don't say what options are chosen to do
the validation. Currently XML Schema is only defined in terms of XML
1.0, so this would suggest serializing as XML 1.0, which has the
fortuitous effect of propagating the namespace scope; but this doesn't
seem a long-term solution.

The problem is particularly acute for xsl:element because it doesn't
inherit namespace nodes from its parents in the stylesheet either.

The most obvious noticeable effect is a proliferation of xmlns=""
undeclarations. If the parent element has a namespace node that binds
the default prefix to some namespace, and if the child element has no
namespace node for the default prefix, then the serializer is required to output
xmlns="". In 1.0 you only get these if the child element actually uses
the default namespace in its element name. We could say that this comes
within the scope of undeclare-namespaces, but that's tricky, because the
serializer can't easily tell whether the absence of a namespace node for the
default namespace is significant or not.

Technically there's probably no backwards incompatibility because XSLT
1.0 defined no way of accessing a result tree without serializing it, and
serializing would always cause any namespace nodes (other than the
default namespace perhaps) to be inherited by child elements because XML 1.0
didn't allow any other option. But I don't feel entirely comfortable about it.

My first thought was to have different rules for xsl:copy-of and
xsl:element but that doesn't work. The semantics describing how nodes are
constructed are now completely separated from the semantics of how they are attached
to a parent element, so the latter process can't depend on what instruction
was used to create the element. 

One could potentially make it a property of the instruction that creates the
parent element, so one could have an attribute propagate-namespaces="yes|no"
on xsl:element, LREs, and xsl:copy. But I don't like that much - 99% of
users would have no idea what it meant. 

The underlying problem seems to be that namespace undeclaration in XML 1.1
is a very positive signal that you don't want the namespace propagated.
Because we use namespace nodes rather than declarations and undeclarations,
we are relying on a negative signal: if you don't explicitly ask for the
namespace at every level, you don't get it. It's hard to see how to
change this without changing the model for namespace nodes, which is something
I don't want to touch with a bargepole.

So I think we have to make a binary choice: should namespace nodes
automatically propagate from parents to children, or not? I'm a bit
inclined at the moment to think that the low-risk approach is to propagate them,
i.e. to revert to the previous specification. This would leave us without any
way of forcing a namespace undeclaration to be output.

Michael Kay

MK: Rules for fixup now say that a child does not automatically
    inherit namespaces of its parent.  Serialization as XML 1.0
    will cause namespaces to be inherited.  Does this cause
    problems for handling QNames in content?
SB: We should discuss this at F2F.

      

Long discussion.
Lunch.
MK proposes new rule in namespace fixup, which affects all element creation.
proposal: for the three instructions which create new elements:
element copy literal-result-elemtns we add a new attribute 'inherit-namespaces'
(in result elements, with xsl:prefix), with values yes (dft), no.
The effect is that if the value 'no' is specified, then the namespace
fixup process behaves as in the current WD, and if 'yes' is specified, then
every hnamespace node in the parent leement to which the new element is attached is copied to the new element, unless the new element already has a namespace node with the asame name.
msm: doesn't that require a thunk?  namespace fixup happens during node
construction, which doesn't know where the node will later get copied.
Ooh.
Plan B: specify donate-namespaces on parent.  Cascade down.,
inherit-ns yes|no.  Effect of specifying yes is that descendants of new
eleent acquire copies of namespace nodes on the new element unless they
or an intermediate element have a conflicting def of the same prefix.
Examples:
 
grandparent has a, b, c1
parent has c2, d
child has e
After propagation, 
grandparent has a, b, c1
parent has a, b, c2, d
child has a, b, e
Default is yes.
We also explored doing just children, not descendants, and found result
unsatisfactory:
after propagation, 
grandparent has a, b, c1
parent has a, b, c2, d
child has e

MHK: the minutes don't record the fact, but Plan B was agreed.
      

This comment was originally raised internally by Jeni Tennison at:

http://lists.w3.org/Archives/Member/w3c-xsl-wg/2003Nov/0007.html
(member-only URL)

Hi,

Just a small thing: the current signature for unparsed-text() is:

  unparsed-text($href as xs:string?) as xs:string
  unparsed-text($href as xs:string?,
                $encoding as xs:string) as xs:string

but I can't see anything in the current draft that says what happens
if the first argument is an empty sequence. Is it treated as an empty
string? Or does the function always return an empty string in this
case?

Cheers,

Jeni
---
Jeni Tennison

MK: What should be the behavior if the href is empty sequence?

Options:
1. Return zero-length string
2. Return empty sequence
3. Change signature to disallow empty sequence for href

NW: I can live with any of these.

MK: Any objections on accepting #2 (returning empty sequence).

No objections.

[*** CHANGE APPLIED - MHK]

This was originally raised at

http://lists.w3.org/Archives/Member/w3c-xsl-wg/2003Nov/0016.html
(member-only URL)

(Note that is comment is against XSLT match patterns only, it doesn't
affect XPath or XQuery)

We currently allow the union operator in a pattern to be written either
as
"|" or as "union". I'm inclined to disallow the "union" synonym. This is
because it doesn't work with "/" as one of the operands. Writing

    / union *

gives you a parse error because "union" after "/" is interpreted as a
QName. Unlike XPath, we don't have the opportunity to disambiguate it by
writing (/) union *, because we don't allow parentheses in a pattern.

   / union /*

is even worse because it doesn't give you a parse error, it just matches
the wrong nodes. 

Adding the synonym doesn't provide any extra functionality or usability
and only introduces a potential problem.

Michael Kay

MK: Disallow 'union' synonym for '/'

MS, NW, AB - agree.

MK: Any objections?

No objections.

ACCEPTED - Removed 'union' in patterns.

[** proposal accepted at telcon 2004-04-01 and announced on public-qt-comments, applied to draft T.]

This was originally raised internally at
http://lists.w3.org/Archives/Member/w3c-xsl-wg/2003Dec/0000.html

See also the replies to that message.

To summarize:

Following up on a bug report from a Saxon user, I've been looking at how
large numbers like 1E25 should be formatted by format-number(). (Saxon
7.8 gets it completely wrong).

After fixing the obvious bug, the expression

<xsl:value-of select="format-number(1E25,'#,######')"/>

produces

10,000000,000000,000905,969664

with the Saxon implementation of the XSLT 2.0 algorithm, while the
JDK-based
implementation produces:

10,000000,000000,000000,000000


Internally, the floating point representation of 1E25 is:

4656612873077393 x 2^31

which is the value that Saxon outputs, converted to decimal. Java
appears to be doing some intelligent rounding of the value.

Questions for us are

(a) should we mandate such rounding?
(b) if so, what are the rules?

A related question is: what if the input is a decimal, rather than a
double?
At the moment, we simply "promote" the decimal to a double, which means
that precision will in general be lost before the conversion to a string. So:

(c) should we try to define format-number() so that decimal values
(including integers) are not converted to doubles before being
formatted?

Michael Kay 

Response from David Marston:

I think the rule is about significant figures. Looking at '1E25', you
can say deterministically that there is one significant figure. That
number should be rendered in such a way that the rendered form can be
interpreted to have one significant figure. In this example,
10,000000,000000,000000,000000
Can be interpreted to have anywhere from 1 to 26 significant figures,
whereas 10,000000,000000,000905,969664
can only be interpreted to have 26.

>(c) should we try to define format-number() so that decimal values
(including integers) are not converted to doubles before being
formatted?

That seems reasonable. Perhaps the document should acknowledge the
potential to produce strings that express more precision than the number
really has, which would cover a multitude of sins. With that disclaimer,
you can proceed to say that the input number is taken as-is (i.e., with
whatever precision it has) and truncated or stretched without regard to
the dececptiveness of the result. 

Response from Michael Kay:

But our input is the IEEE floating point number represented by 1E25,
which is equal to 10,000000,000000,000905,969664 . 
 
I would like to define that we produce a "rounded" representation, but
I'm not sure how to achieve it. It can't be based on the original lexical
form: we have no idea whether the number started life as "1E25" or as
10000000000000000905969664E0. 
 
Michael Kay

Discussion on this email.

MK: General feeling is that something needs to be done, and we need a 
proposal.

NW: I will try to find resources to help produce the proposal.

ACTION - Norm to find someone who might be number formatting expert,
to write the proposal.

Those involved in attempting to resolve this discussion _may_ find the
discussion from the last but one XML Schema WG f2f (see minutes at
[1], seach for "RQ-1 canonical float/double") helpful, since the
situation is somewhat analogous (or so it seems to me): in both cases,
we are trying to output a decimal numeral for which the binary value
we have to work from has insufficiently detail.

ht

[1] http://www.w3.org/XML/Group/2004/01/xml-schema-ftf-minutes
-- 
 Henry S. Thompson, HCRC Language Technology Group, University of Edinburgh

>    Proposed resolution at
>    http://lists.w3.org/Archives/Member/w3c-xsl-wg/2004Jun/0011.html

Proposal: Change signature so it accepts numeric - prevents xs:decimal
     from losing precision in promotion to xs:double.  Then, treat
     value as if you have infinite precision representation as a string.
     Given two different string representations, prefer the value
     that has the fewest digits that would give you the value you
     started with if you converted the value back to a value of the
     same type.
MK: With digits to right of decimal, picture controls how many
    digits.  Problem really comes up with digits to left of decimal.

**Accepted, subject to members reviewing with their implementers.

** Changes applied to draft U - MHK.


      

This issue was originally raised at
 http://lists.w3.org/Archives/Member/w3c-xsl-wg/2003Dec/0005.html
(member-only link)

Here is a copy, updated to reflect subsequent correspondence:

There is an error in the published schema for XSLT. The element
declaration for xsl:text is a complex type with simple content, but it
is derived by extension from a complex type with complex content. 

Presumably we should fix this by restricting xsl:versioned-element-type
to
constrain it to have simple content, and then to extend it to allow the
disable-output-escaping attribute. The current definition is:

<xs:element name="text" substitutionGroup="xsl:instruction">
  <xs:complexType>
    <xs:simpleContent>
      <xs:extension base="xsl:versioned-element-type">
        <xs:attribute name="disable-output-escaping"
             type="xsl:yes-or-no" default="no"/>
      </xs:extension>
    </xs:simpleContent>
  </xs:complexType>
</xs:element>

Note that a separate proposal to combine xsl:text and xsl:value-of,
making them synonyms, would automatically fix this problem.

Michael Kay 

My suggested fix, as discussed on the call just now, is as follows:

<xs:complexType name="versioned-element-text-type">
 <xs:simpleContent>
  <xs:restriction base="xsl:versioned-element-type">
   <xs:simpleType>
    <xs:restriction base="xs:string"/>
   </xs:simpleType>
  </xs:restriction>
 </xs:simpleType>
</xs:complexType>

<xs:element name="text" substitutionGroup="xsl:instruction">
  <xs:complexType>
    <xs:simpleContent>
      <xs:extension base="xsl:versioned-element-text-type">
        <xs:attribute name="disable-output-escaping"
             type="xsl:yes-or-no" default="no"/>
      </xs:extension>
    </xs:simpleContent>
  </xs:complexType>
</xs:element>

ht
-- 
 Henry S. Thompson, HCRC Language Technology Group, University of Edinburgh

 [*** CHANGE APPLIED - MHK]

[XSLT2.0] Binding of a local xsl:variable or xsl:param by another local
xsl:variable/xsl:param

The section "9.7 Scope of Variables" at
http://www.w3.org/TR/xslt20/#scope-of-variables contains the following
text:

<quote>
For any variable-binding element, there is a region of the stylesheet
within which the binding is visible. The set of variable bindings in scope
for an XPath expression consists of those bindings that are visible at the
point in the stylesheet where the expression occurs.

A global variable binding element is visible everywhere in the stylesheet
(including other stylesheet modules) except within the xsl:variable or
xsl:param element itself and any region where it is shadowed by another
variable binding.

A local variable binding element is visible for all following siblings and
their descendants. The binding is not visible for the xsl:variable or
xsl:param element itself.

[Definition: A binding shadows another binding if the binding occurs at a
point where the other binding is visible, and the bindings have the same
name. ] It is not an error if a binding established by a local
xsl:variable or xsl:param shadows a global binding. In this case, the
global binding will not be visible in the region of the stylesheet where
it is shadowed by the other binding.

Example: Local Variable Shadowing a Global Variable 
The following is allowed:
<xsl:param name="x" select="1"/>
<xsl:template name="foo">
  <xsl:variable name="x" select="2"/>
</xsl:template>

It is also not an error if a binding established by a local xsl:variable
or xsl:param element shadows another binding established by another local
xsl:variable or xsl:param. However, such shadowing is discouraged and
implementations may output a warning when it occurs.

Example: Local Variable Shadowing a Local Variable 
The following is not an error, but is discouraged, because the effect is
probably not what was intended. The template outputs 
<x value="1"/>, 
because the declaration of the inner variable named $x has no effect on
the value of the outer variable named $x.

<xsl:template name="foo">
  <xsl:variable name="x" select="1"/>
  <xsl:for-each select="1 to 5">
    <xsl:variable name="x" select="$x+1"/>
  </xsl:for-each>
  <x value="{$x}"/>
</xsl:template>

Note:
Once a variable has been given a value, the value cannot subsequently be
changed. XSLT does not provide an equivalent to the assignment operator
available in many procedural programming languages.
This is because an assignment operator would make it harder to create an
implementation that processes a document other than in a batch-like way,
starting at the beginning and continuing through to the end.

As well as global variables and local variables, an XPath expression may
also declare range variables for use locally within an expression. For
details, see [XPath 2.0].
Where a reference to a variable occurs in an XPath expression, it is
resolved first by reference to range variables that are in scope, then by
reference to local variables and parameters, and finally by reference to
global variables and parameters. A range variable may shadow a local
variable or a global variable. XPath also allows a range variable to
shadow another range variable.
</quote>

I. Problems
There are several problems with this text and especially with the proposed
shadowing of a local xsl:variable or xsl:param element by another local
xsl:variable or xsl:param element:

1. The statement 
"A local variable binding element is visible for all following siblings
and their descendants. The binding is not visible for the xsl:variable or
xsl:param element itself".

is not true.

In case a local variable binding element is shadowed by another local
variable binding element, then it is not visible by all of its following
siblings and their descendents. The first local variable binding element
is only visible by those of its following siblings (and their
descendents), which are preceding siblings of the second local variable
element, which shadows the first.

2. In all cases of a local variable binding being shadowed by another
local variable binding the XSLT programmer can only manually try to
identify the correct variable binding for a given variable reference -- a
manual backwards text analysis is required in order to find the last
xsl:variable or xsl:parameter definition with the same name as the name of
the variable being referenced. This manual process is difficult,
error-prone and unreliable.

3. The lack of syntactic markers of the scope (called region!?! in the
draft) for a local variable binding is in violation of a number of
good-programming principles:

  - abstraction
  - encapsulation
  - consistent naming and elimination of ambiguities and redundancies.
  - the ability to easily and unambiguously identify the corresponding
variable definition from a given variable reference.


This leads to difficulties in understanding the code of a stylesheet. 
With the need to manually track and identify one of a many possible local
variable bindings that may or may not be referenced by a reference to a
given variable, the process of understanding, maintaining or debugging an
XSLT application becomes essentially difficult, error-prone and
unreliable, which in general will lead to increasing the costs of
development of an XSLT application.


II. Questions

Based on the facts listed above a number of questions do arise:

1. Why was it necessary to include a feature and immediately after
describing it to warn that use of this feature should be discouraged:

"It is also not an error if a binding established by a local xsl:variable
or xsl:param element shadows another binding established by another local
xsl:variable or xsl:param. However, such shadowing is discouraged and
implementations may output a warning when it occurs."

2. Was there any XSLT 2.0 use-case for the need to shadow a local
xsl:variable or xsl:param binding with another local xsl:variable or
xsl:param binding? Which one?

3. Which other programming language is popular for allowing multiple
identically named variables in the same lexical scope?

4. Was there a single WG member, who uses XSLT regularly in his/her work,
who voted positively for this feature?


III. Proposal

Taking into acount the harmful effects of local shadowing as listed above,
the specification should be corrected to explicitly state that it is
illegal in XSLT 2.0 for a local variable binding to shadow another local
variable binding, which is its sibling.


I hope that the respected members of the XSLT 2.0 WG will analyze the
facts, conclusions and proposal contained in this comment and will take
the correct decision.


Dimitre Novatchev.

See also subsequent discussion:

http://lists.w3.org/Archives/Public/public-qt-comments/2004Feb/0113.html
http://lists.w3.org/Archives/Public/public-qt-comments/2004Feb/0115.html
http://lists.w3.org/Archives/Public/public-qt-comments/2004Feb/0116.html
http://lists.w3.org/Archives/Public/public-qt-comments/2004Feb/0117.html

This is an XSL WG response to the message

http://lists.w3.org/Archives/Public/public-qt-comments/2004Feb/0111.html

(issue qt-2004Feb0111-01)

In summary, the WG decided to make no technical change in response to this
comment. 

It's a difficult issue with arguments on both sides. There are respectable
programming languages that do it one way, and there are respectable
languages that do it the other way. There is no objective way of saying that
one group are right and the other are wrong. I therefore can't give a
convincing technical argument in favour of the decision to allow variable
shadowing. Opinions within the XSL WG are fairly evenly balanced on the
issue. Opinions in the XQuery group, however, have been strongly in favour
of allowing variable shadowing. There is therefore little prospect of
changing the rule at the XPath level, and given that fact, the XSL WG feels
it is better for XSLT and XPath to be consistent.

The technical arguments in favour of allowing variable shadowing seem to be
summarized under the heading "no needless restrictions". Things shouldn't be
disallowed if they make sense.

Addressing the specific points made:

I.1 is essentially an editorial criticism, suggesting that our use of the
word "visible" is inappropriate. We accept this criticism and will change
the way we describe the language rules.

I.2 suggests that it will be difficult for users to identify which variable
declaration a given variable reference refers to. This is a subjective
argument. It could be equally be used to justify other changes, for example
banning local variables that shadow global variables, or banning the use of
uppercase Greek letters in variable names. The choice of distinctive
variable names for distinct variables is not something that the language can
impose.

I.3 seems to be essentially a re-statement of I.2 in more technical
language, but still essentially in subjective terms.

II.1 Why include the feature and then discourage its use? I think most
people with experience of developing standards will recognize this as a
classic thing that happens when there are good arguments both ways and a
group has to reach a compromise. There are many constructs that we allow
even though we wouldn't recommend their use in most circumstances, for
example the expression "$A/$B": this is another example where some wanted to
ban it but the "no needless restrictions" argument won the day.

II.2 Was there any XSLT 2.0 use case for the need to allow shadowing? The
only use case I recall being presented is the "cut and paste" use case: it
should be possible to copy code from one place to another without renaming
all the variables. But this isn't why the decision was made: it was made
because XQuery didn't want to introduce what they saw as an unnecessary
restriction into their language, and XSLT agreed that it was desirable for
the XSLT and XPath to be consistent.

II.3 Which other programming language is popular [for allowing this
feature]? When we first debated this issue, other languages were surveyed,
and we found there was no overwhelming precedent one way or the other. I
regret I don't have this analysis to hand now. I wouldn't claim it was
comprehensive - it probably looked at 8 languages rather than 80.

II.4 Was there a single WG member who uses XSLT regularly who voted for this
feature? Dimitre, we know you feel passionately about this, but asking this
sort of ad hominem question is not going to help your case. Of course the
simple answer is yes. I would say, however, that the overwhelming majority
of the WG could live with it going either way.

I know you're not going to like this decision, but we can't please everyone
all of the time. I have to ask you if you will accept it.

Regards,

Michael Kay
for the XSL Working Group
 

Hi Michael,

--- Michael Kay <mhk@mhk.me.uk> wrote:
> This is an XSL WG response to the message
> 
> http://lists.w3.org/Archives/Public/public-qt-comments/2004Feb/0111.html
> 
> (issue qt-2004Feb0111-01)
> 
> In summary, the WG decided to make no technical change in response to
> this
> comment. 

As someone else said it: it's a shame.

Until now I believed that XSLT 2.0 could be an elegant language. Thank you
for showing to me and to everybody that this was not a realistic belief.

I do not agree with at least two of the points in the WG reply:

> Addressing the specific points made:

 . . . . . . . .

> I.2 suggests that it will be difficult for users to identify which
> variable declaration a given variable reference refers to. This is a 
> subjective argument. It could be equally be used to justify other 
> changes, for example banning local variables that shadow global 
> variables

This is not subjective argument and the answer above shows that the WG did
not understand at all the issue raised.

In the case of a local variable shadowing a global one there is absolutely
no problem to identify the variable declaration -- it is the only one
declaration for the variable with this name in the current template.

The case when shadowing is allowed between two local variables is
completely different. There may be many variable declarations for
variables with the same name within a template. In order to determine
which is the corresponding declaration for "this" variable (note the
naming difficulty! it will be necessary to stick one's finger to the
variable reference in order to identify it! One cannot just say variable
"abc", nor even variable "abc" - occurrence N) one will have to print the
file, then stick a finger at the variable reference and scroll backwards
(not releasing the finger pointing to the reference) until the first
preceding variable declaration for this name is found.

Then use a coloured pen to hi-light the scope of exactly "this" variable.

Imagine the case when two or more different variables are used in an
expression and these variables have overlapping scopes. It would be
necessary to manually determine the scope of each variable and then the
intersection of all scopes -- isn't this a real programmer's hell?



> II.2 Was there any XSLT 2.0 use case for the need to allow shadowing?
> The only use case I recall being presented is the "cut and paste" use 
>case:
> it should be possible to copy code from one place to another without
> renaming all the variables. 

It is perfectly clear that allowing shadowing of one local variable by
another does not provide a solution to this "cut and paste" "use case".

The pasted text may not contain a definition for a variable reference and
then the one in the first text will be used with potentially catastrophic
results.

Or the pasted text (containing all necessary variable declarations) may be
inserted in the middle of the scope of a variable declaration, thus
leaving some of the last references to the original variable refer to the
variable declaration of the pasted text and not to its original variable
declaration. The results again would be catastrophic.

Not even to speak about the real usefulness of such use case...

> I know you're not going to like this decision, but we can't please
> everyone all of the time. I have to ask you if you will accept it.
> 

Michael, it is not for my own pleasure that I am writing these comments.

What we are talking about is the new XSLT 2.0 language and whether it
would be elegant or ugly, easy and intuitive to use or supporting mistakes
and difficult for the programmer to use and understand.

This will be the "XSLT designed by committee". Isn't it time for people,
who love XSLT to design their own language?

Best regards,

Dimitre Novatchev.

qt-2004Feb0111-01: [XSLT2.0] Binding of a local xsl:variable or xsl:param by another local xsl:variable/xsl:param
http://lists.w3.org/Archives/Member/member-query-specs/2004Jun/att-0006/issues.html#qt-2004Feb0111-01
Long hard discussion.  Arguments both ways.  Consistency with query, 
cost of change.  
KK: the example should be written up as showing dangers of shadowing,
not specifically local:local shadowing.  Also, don't say allowed but
discouraged.
CLOSED:  issue considered but did not command consensus.  Rationale: consistency
with Query.

ACTION Mike: rewrite note. DONE-MHK
ACTION: Mike to respond to commentator. DONE-MHK
      

Hi,

In XSLT1.1, attributes like method and indent could easily be parametrized 
or calculated.for the xsl:document instruction, allowing one, for example, 
to render some documents in HTML, others in XML, some with indentation, 
some not.

With XSLT2.0, there seems to be no way to parametrize the output format of 
a document :

One can define multiple corresponding xsl:output instructions, each with a 
different specific combination of output format attributes;  then one can 
define an xsl:result-document instruction and assign the corresponding 
xsl:output format name to the xsl:result-document format attribute, but the 
format attribute is a litteral QName and cannot be assigned, calculated, or 
parametrized, even with cast to xs:QName.  The only remaining alternative 
is to duplicate the xsl:result-document instruction block (and an 
xsl:output instruction) for every possible xsl:output attribute value 
combination and to xsl:choose between them, based on the specific values 
and their combination.

I find this inelegant, clumsy, redundant and difficult to maintain.

Why can't result-document have its own output attributes ?

If not, why can't the xsl:result-document format attribute be assigned a 
value other than a litteral QName ?

Serializing output documents is a fundamental operation in XSLT and it 
should be parametrizable.

Why separate the output format attribute from the only instruction that 
uses them ?

Why force a litteral QName to join them later ?

Thank you.

Andre


Here is some sample code of what it may look like in XSLT2.0 if you could 
assign to the format attribute.  Now, this does not work.

         <xsl:output name="xmlyes" method="xml" version="1.0" 
encoding="ISO-8859-1" omit-xml-declaration="no" indent="yes" 
media-type="text/html"/>
         <xsl:output name="xmlno" method="xml" version="1.0" 
encoding="ISO-8859-1" omit-xml-declaration="no" indent="no" 
media-type="text/html"/>
         <xsl:output name="htmlyes" method="html" version="1.0" 
encoding="ISO-8859-1" omit-xml-declaration="no" indent="yes" 
media-type="text/html"/>
         <xsl:output name="htmlno" method="html" version="1.0" 
encoding="ISO-8859-1" omit-xml-declaration="no" indent="no" 
media-type="text/html"/>
...
         <xsl:template name="persist-file">
...
                 <xsl:result-document href="filename" 
format="{xs:QName(concat(@method, @indent))}">
                         <xsl:apply-templates mode="buildpage" select="."/>
                 </xsl:result-document>

or even

                 <xsl:result-document href="filename">
                         <xsl:attribute name="format"><xsl:value-of 
select="xs:QName(concat(@method, @indent))"/></xsl:attribute>
                         <xsl:apply-templates mode="buildpage" select="."/>
                 </xsl:result-document>
...
         </xsl:template>



Here is a sample of what works today, if we only have four attribute value 
combinations :

         <xsl:output name="xmlyes" method="xml" version="1.0" 
encoding="ISO-8859-1" omit-xml-declaration="no" indent="yes" 
media-type="text/html"/>
         <xsl:output name="xmlno" method="xml" version="1.0" 
encoding="ISO-8859-1" omit-xml-declaration="no" indent="no" 
media-type="text/html"/>
         <xsl:output name="htmlyes" method="html" version="1.0" 
encoding="ISO-8859-1" omit-xml-declaration="no" indent="yes" 
media-type="text/html"/>
         <xsl:output name="htmlno" method="html" version="1.0" 
encoding="ISO-8859-1" omit-xml-declaration="no" indent="no" 
media-type="text/html"/>
...
         <xsl:template name="persist-file">
...
                 <xsl:choose>
		<xsl:when test="@indent = 'yes' ">
			<xsl:choose>
				<xsl:when test="@method = 'xml' ">
					<xsl:result-document href="filename" format="xmlyes">
				                        <xsl:apply-templates mode="buildpage" select="."/>
			                	</xsl:result-document>
				</xsl:when>
				<xsl:when test="@method = 'html' ">
					<xsl:result-document href="filename" format="htmlyes">
				                        <xsl:apply-templates mode="buildpage" select="."/>
			                	</xsl:result-document>
				</xsl:when>
			</xsl:choose>
		<xsl:when>
		<xsl:when test="@indent = 'no' ">
			<xsl:choose>
				<xsl:when test="@method = 'xml' ">
					<xsl:result-document href="filename" format="xmlno">
				                        <xsl:apply-templates mode="buildpage" select="."/>
			                	</xsl:result-document>
				</xsl:when>
				<xsl:when test="@method = 'html' ">
					<xsl:result-document href="filename" format="xmlno">
				                        <xsl:apply-templates mode="buildpage" select="."/>
			                	</xsl:result-document>
				</xsl:when>
			</xsl:choose>
		<xsl:when>
	      </xsl:choose>
...
         </xsl:template>


Finally, in XSLT1.1, this is all that is required (whatever the number of 
attribute value combinations) isn't this much nicer ?

         <xsl:template name="persist-file">
...
		<xsl:document href="filename" method="@method" indent="@indent" 
version="@version" media-type="@media-type" encoding="@encoding" 
omit-xml-declaration="@omit-xml-declaration">
		        <xsl:apply-templates mode="buildpage" select="."/>
		</xsl:result-document>
...
         </xsl:template>


What happens, in XSLT2.0, if we need to support more methods and if we also 
need to vary the version number, the encoding, the omit-xml-declaration, 
and the media-type ?


MHK response (equivocal): 
http://lists.w3.org/Archives/Public/public-qt-comments/2004Feb/0161.html

Andre Cusson message fixing a typo in the original:
http://lists.w3.org/Archives/Public/public-qt-comments/2004Feb/0162.html

         Summary: a detailed discussion that came to no conclusions.

         

            
 
4C.Unrecorded action: Mark and Scott were going  to go back to their
implementors and discuss AVTs on serialization  attributes (re:
http://lists.w3.org/Archives/Member/member-query-specs/2004Apr/att-0004/new-
issues.html#qt-2004Feb0160-01
).

There was discussion on this last week and no  decision. Do we have any
further input to make progress?



Discussion led to:

***Action *** MK document as a proposal
-----------------------

[Proposal written, see http://lists.w3.org/Archives/Member/w3c-xsl-wg/2004May/0035.html

            
Following discussion on this last week, my proposal is:

xsl:result-document should have the following optional properties added:

  method? = {"xml" | "html" | "xhtml" | "text" | qname-but-not-ncname}
  cdata-section-elements? = {qnames}
  doctype-public? = {string}
  doctype-system? = {string}
  encoding? = {string}
  escape-uri-attributes? = {"yes" | "no"}
  include-content-type? = {"yes" | "no"}
  indent? = {"yes" | "no"}
  media-type? = {string}
  normalize-unicode? = {"yes" | "no"}
  omit-xml-declaration? = {"yes" | "no"}
  standalone? = {"yes" | "no"}
  undeclare-namespaces? = {"yes" | "no"}
  use-character-maps? = {qnames}
  version? = {nmtoken} />

Note the curly braces which indicate that all these attributes are AVTs.

The default value for each serialization attribute is taken from the
xsl:output declaration named in the "format" attribute (which is not an
AVT), or the unnamed xsl:output declaration if there is no "format"
attribute.

For any serialization attribute specified in the xsl:result-document
declaration, the specified value overrides the value given in the base
xsl:output declaration; except for cdata-section-elements and
use-character-maps, where the specified value supplements the base value.
(This matches the rules when one xsl:output declaration overrides another of
lower import precedence.)

OPTION A: remove "use-character-maps" from this list, on the grounds that
life is much easier for implementers if character maps can always be
assembled at compile time.

OPTION B: remove the "format" attribute of xsl:result-document and the
"name" attribute of xsl:output, so serialization properties are specified
only using the xsl:result-document attributes.

Michael Kay             
            
         

MK has sent an outline to the list.
Kris has changed the topic to 
http://lists.w3.org/Archives/Member/w3c-xsl-wg/2004May/0035.html
MK: "option a" use character maps. There are reasons to not use character 
maps...MS agrees. Could provide the attribute without AVT.
SB: option A w/o AVT and option B.
(no objections raised)
MK: FYI, normalize-unicode should be normalize-form.
DECISION: Proposal adopted with: option A "yes" but not as AVT, and option 
B "no".

*** SPEC UPDATED
     
      

Andre Cusson raised a comment at:

http://lists.w3.org/Archives/Public/public-qt-comments/2004Feb/0160.html

Our reference: qt-2004Feb0160-01

The XSL WG debated this comment over a period of time and decided on 20th
May to accept a proposal along essentially the lines suggested in the
original comment.

The effect is that all the serialization attributes defined on xsl:output
are now also defined on xsl:result-document. With the exception of
use-character-maps, they can all be AVTs. (This exception ensures that a
composite character map can always be constructed at compile time.) The
ability for xsl:result-document to reference a named output format remains,
and the attributes defined on xsl:result-document override (or in the case
of cdata-section-elements and use-character-maps, supplement) the attributes
in the base output definition.

Andre, I trust you will find this a satisfactory outcome.

Michael Kay
for the XSL WG

Comment on: 12.3, first paragraph after the bulleted list:

There are numbering sequences whose intrinsic limit is less than 1000.
For example, the formatting token ① (circled digit one) has
a limit of 20 imposed by the Unicode character repertoire.
Thus the second last sentence in the paragraph needs to be changed to
read:

 For the numbering sequences described above,
 any upper bound imposed by the implementation must not be
 less than 1000 (one thousand).

to make it clear that it is any IMPLEMENTATION imposed limit that may not
be less than 1000.

>    This proposal was accepted and the text has been revised but the 
decision
>    does not appear to have been recorded in the issues list.

      

COMMENT 2 of 2 : (EDITORIAL TYPO)

Two periods at end of sentence:

     This includes, without loss of generality, conflicts such
     as multiple definitions of the same name..

Xan Gregg, on behalf of the XML Schema Working Group

Thank you for the comment. 

I have fixed the typo, and I will assume your tacit agreement that this
closure is acceptable.

Michael Kay
(speaking as XSLT 2.0 editor)

** change applied to document - MHK

Status changed to "announced"

Originator deemed to have accepted

COMMENT 1 of 2 : XMLSchema-datatypes namespace URI

In section 3.2 "Reserved Namespaces", the XMLSchema-datatypes URI is
listed with the following comment:

      [Definition: The schema datatypes namespace
      http://www.w3.org/2001/XMLSchema-datatypes is used as defined
      in [XML Schema]]. In a stylesheet this namespace may be used to
      refer to built-in schema datatypes and to the constructor functions
      associated with those datatypes: in these respects it is equivalent
      to the schema namespace.

Please note that the Schema WG has an open issue, R-222 [1], on the
topic of the alternate datatypes namespace, which we consider to be
problematic. We have not reached consensus among the following options:

    - declare the types in the datatypes namespace as a magic aliases,
      violating the principle of at most one name per component
    - define the types in the datatypes namespace as vacuous restrictions
      of the corresponding types in the schema namespace, which means,
      for instance, that xdt:integer is not derived from xdt:decimal
    - deprecate the datatypes namespace

We apologize for this issue being unresolved; that being the state, the
safest course of action would be for XSLT to avoid using the datatypes
namespace.

Xan Gregg, on behalf of the XML Schema Working Group

[1] XML Schema Issues List (version with R-222 not yet published to web 
site)
http://www.w3.org/2001/05/xmlschema-rec-comments

This is a response to the following comment on XSLT 2.0 from the Schema
Working Group 

http://lists.w3.org/Archives/Public/public-qt-comments/2004Feb/0253.html

(our reference: issue qt-2004Feb0253-01)

The comment concerns the reference in the XSLT specification to the The
schema datatypes namespace http://www.w3.org/2001/XMLSchema-datatypes

The XSL WG accepts the comment gratefully and has decided to remove all
reference to this namespace from the specification.

Michael Kay
for the XSL Working Group

The XML Schema WG is satisfied with your response.  Thank you.

Xan Gregg
on behalf of the XML Schema WG

On Apr 30, 2004, at 6:54 PM, Michael Kay wrote:

> This is a response to the following comment on XSLT 2.0 from the Schema
> Working Group
>
> http://lists.w3.org/Archives/Public/public-qt-comments/2004Feb/ 
> 0253.html
>
> (our reference: issue qt-2004Feb0253-01)
>
> The comment concerns the reference in the XSLT specification to the The
> schema datatypes namespace http://www.w3.org/2001/XMLSchema-datatypes
>
> The XSL WG accepts the comment gratefully and has decided to remove all
> reference to this namespace from the specification.
>
> Michael Kay
> for the XSL Working Group

SECTION 11.8.2: Deep Copy

The note states: "This is because failing to copy the namespace nodes
may cause QName values in the content of an element to become invalid."
however, even if copy-namespaces="no", namespace fixup process still
creates namespace nodes. Thus there is no need for this static error
as this condition will not occur.

Regards,
Mark Scardina
Oracle Corporation

MHK personal response:
 
I think this comment is correct, as far as element nodes are concerned.
 
However, I think there is a related problem concerning attribute nodes. It
is not safe to copy the type annotation of an attribute node if the type
annotation is xs:QName. So I think we should replace the existing error
condition with a new dynamic error: when copying an attribute node it is an
error to specify validation="preserve" if the typed value of the attribute
is, or is derived from, xs:QName or xs:NOTATION.
 
Michael Kay

Summary: after discussion, the Oracle comment was agreed.

Clarification in minutes of 2004-03-25:

We agreed accept the Oracle comment - removing an error condition.

A new comment has been raised by Mike Kay (on qt comments list).

Action Sharon to put this new comment on joint F2F agenda.

[*** SPEC UPDATED - MHK]

SECTION 15.2: Captured Substrings

Current Captured Substrings are missing from the XPath dynamic context. 

The first sentence in the Definition should be replaced with: 
The <xsl:matching-substring> initializes the stylesheet evaluation context
 "current captured substrings" component with the result of regular expression evaluation ...".

Regards,
Mark Scardina
Oracle Corporation

 
MHK personal response:
 
I agree with what I see as the intent of this proposal, namely to marry up
the description in 15.2 with the definition of "additional context
variables" in section 2.5.2. I think we can do better on the wording.
 
Michael Kay

 

Summary: the editor acknowledges that the spec doesn't formalize this, and
could be worded better. But is the work really necessary?

Disposition: Action on Mark to discuss internally and come back.

Mark: the "extra" context is not "exposed" and has no interoperability
issues. It seems sufficient for XSLT to specify that this information
is "saved" and "passed" appropriately.

Action Mike Kay to add cross references to sections that describe the
extra context information.

This closes this issue.

** 2004-04-28: changes not yet made, therefore this issue still not completed.

Subsequently: the spec was revised to formalize the additional variables added by XSLT
to the dynamic context.   
   
   
   

SECTION 13.1.1: the sorting process

"If all the sort key values compare equal, then A will precede B 
in the sorted sequence if and only if A preceded B in the initial 
sequence." This restriction has performance consequences. 
Suggest adding an attribute to xsl:sort to such as stable="yes|no". 
XQuery has this option in ORDER BY.


Regards,
Mark Scardina
Oracle Corporation

The XSL Working Group agreed in principle to add this feature, and asked
me to put forward a detailed specification.

This is what I propose:

The <xsl:sort> element gets a new optional attribute, stable, whose
permitted values are "yes" and "no". Like other sort attributes, it can
be an AVT.

This attribute is permitted only on the first xsl:sort element within a
"sort key specification" [i.e. of a sequence of sibling xsl:sort
elements]. A new static error condition is defined if the attribute is
present on any element after the first.

The default value is "yes".

We define that a sort specification is stable unless stable="no" is
specified on its first sort key.

The sentence:

<old>
If all the sort key values compare equal, then A will precede B in the
sorted sequence if and only if A preceded B in the initial sequence.
</old>

changes to:

<new>
If all the sort key values compare equal, then:

 * if the sort specification is stable then A will precede B in the
sorted sequence if and only if A preceded B in the initial sequence;
 
 * if the sort specification is not stable then the relative order of A
and B in the sorted sequence is implementation-dependent.
</new>

We also need to adjust the Note that follows this sentence.

Michael Kay

*** MHK note 2004-04-28. This proposal was accepted. According to the minutes
of 2004-03-15 it was accepted "a few weeks ago". I haven't located the minutes
that record the decision. The proposed text has been added to the base document.

SECTION 9.5: Global Variables and Parameters

2nd Definition - if the value of a mandatory top-level param is
 not passed by implementation-defined caller, please describe
  the error condition. Please make a reference to ERRXT0050 if applicable.

Regards,
Mark Scardina
Oracle Corporation

 
MHK response:
 
The error condition is indeed ERR XT0050. I believe that the problem can be
resolved editorially by cross-referencing this error condition, as you
suggest.
 
Please confirm that this solution is acceptable.
 
Thanks for this and your other comments.
 
Michael Kay

** added an Ed Note identifying where the change needs to be made - MHK

** ORACLE accepted this resolution orally during 2004-03-18 telcon

SECTION 18.1.1: Testing Availability of Functions

Shouldn't we add an optional argument (type of integer) to function-available() indicating the
 value of arity?
User-defined functions may have same name but different arity. If the check is only based on name,
 function-available() may return true, when it should be false.

Regards,
Mark Scardina
Oracle Corporation

Agreed to add a 2-argument version of the function.

** spec drafted and posted to public-qt-comments for approval. - MHK

** Oliver Becker remarked on the retained wording:
http://lists.w3.org/Archives/Public/public-qt-comments/2004Feb/1093.html

** Resolution confirmed at 2004-03-18 telcon

** Spec has been updated - MHK

Changed status to "announced"

SECTION 12.2: Numbering based on Position in a Document

"[ERR XT1000] It is a type error if the result of evaluating
 the select attribute of the xsl:number instruction is anything other than a single node."

This is not a type error but a dynamic error.

Regards,
Mark Scardina
Oracle Corporation

 
Could you explain why? It's an error that a system can detect statically
if it does static type inference, so in my book that makes it a type
error.

Michael Kay

** Agreed at 2004-03-18 telcon to take no action on this comment.

This email completes the action item, I took on March 18 to look at the 
type errors raised in XSLT (resulting from the discussion on Oracle 
comment ORA-XS-380-B).

All the types errors are raised consistently and correctly, so we can 
close the qt-2004Feb0619-01 without any change.

I am attaching my analysis of the type errors in XSLT (excluding errors 
related to validation). It includes few editorial suggestions related to 
type errors.

Thanks
Karun

qt-2004Feb0619-01: ORA-XS-380-B: Type Errors in XSLT
http://lists.w3.org/Archives/Member/w3c-xsl-wg/2004Mar/0051.html

Karun explains the email.

MK: Any objections accepting the editorial changes?

MK: None, accepted. Close the public comment.

*** MHK note 2004-04-28: the editorial suggestions have either all been applied,
or have been captured in ednotes in the document text.

SECTION 10.2 et. al.: named attribute sets

Whitespace-separated and space-separated are used throughout interchangeably but technically 
mean different sets of characters. This needs to be fixed.

Example: 10.2

"The value of the [xsl:]use-attribute-sets attribute is in each case a whitespace-separated 
list of names of attribute sets" yet 

"[ERR XT0710] It is a static error if the value of the use-attribute-sets attribute of an 
xsl:copy, xsl:element, or xsl:attribute-set element, or the xsl:use-attribute-sets 
attribute of a literal result element, is not a space-separated sequence of QNames, 
" speaks of space-separated. Which is it?

Regards,
Mark Scardina
Oracle Corporation

I believe this issue is editorial and I propose to fix it as follows.

(a) In 6.5 Modes:

change "its value must be a space-separated list of tokens"

to say whitespace-separated.

(b) In ERR0710, change space-separated to say whitespace-separated

(c) In 11.2, xsl:element, change "The <elb>xsl:element</elb> element may have a
<b>use-attribute-sets</b> attribute, whose value is a space-separated list of QNames" to say "whitespace-separated".

(d) Ditto in 11.8.1, xsl:copy

(e) In 20.1 Serialization change "The cdata-section-elements attribute is a space-separated list of QNames" to say "whitespace-separated"

The other place where space-separated appears it is correct.

Can you please confirm that this resolution is acceptable?

Thank you for pointing out this error,

Michael Kay
acting as XSL WG editor

** change made - MHK

Changed status to "announced"

Whitespace-separated is fine also any reference to #20 should be updated
as well.

SECTION 14.2: The Current Grouping Key

The XPath evaluation context does not include current grouping key.

The phrase related to XPath evaluation context:  "... additional 
"value" called  the current grouping key" should be replaced with "component".

Regards,
Mark Scardina
Oracle Corporation

It is acceptable to keep the text as is but add additional cross references.
 
Regards,

Mark

SECTION 14.1: The Current Group

The XPath evaluation context does not include current group.

The phrase related to XPath evaluation context:  "... additional "value" called
 the current group" should be replaced with "component".

Regards,
Mark Scardina
Oracle Corporation

It is acceptable to keep the text as is but add additional cross references.
 
Regards,

Mark

** MHK: changed "additional value" to "additional component". (draft U)

SECTION 11.9: Constructing Sequences

Shouldn't for consistency, the "as" attribute be on every instruction
 returning a sequence or only functions, templates, variables and parameters? 


Regards,
Mark Scardina
Oracle Corporation

 
MHK personal response:
 
It doesn't feel right to me to add this attribute to xsl:element,
xsl:attribute, xsl:comment, and the like.
 
We could add it to xsl:copy and xsl:copy-of, which would make them more
consistent with xsl:sequence. Alternatively, we could remove it from
xsl:sequence. This would leave XSLT declaring types in the places where
other languages declare types: namely on variable and function declarations.
 
Michael Kay

** Decided at 2004-03-18 telcon to remove the "as" attribute from xsl:sequence. 
  (change applied).
Subsequent email proposed dropping the option for xsl:sequence to have content.
 

SECTION 11.6: Creating Namespace Nodes

The attribute value in the first example:
    ... select="http//www.w3.org/2001/XMLSchema" ...
should be replaced with:
    ... select="'http//www.w3.org/2001/XMLSchema'" ...


Regards,
Mark Scardina
Oracle Corporation

Thank you. This comment is a duplicate of

http://lists.w3.org/Archives/Public/public-qt-comments/2004Feb/0105.html

and the correction has already been made. 

Michael Kay

This is a duplicate

Tacitly acknowledged

SECTION 10.3: 

" If the value cannot be converted to the required type, a type exception is signaled.
 If the as attribute is omitted, no conversion takes place and any value is accepted."

The phrase "type exception" should be replaced with "type error" as it is not defined. 

Regards,
Mark Scardina
Oracle Corporation

Thank you for pointing this out. I believe this is an editorial correction, and I will make 
the change requested. I will also allocate the new error code ERR0790 to this error.

Please let me know if this resolution is acceptable.

Regards

Michael Kay
as XSL WG editor

** change made - MHK

Change made

(Tacitly acknowledged)

SECTION 6.3: applying template rules

While <xsl:strip-space elements="*" /> strips only whitespace
<xsl:apply-templates select="*"/> strips more than whitespace and
therefore will not yield equivalent results. (i.e input had
non-whitespace text nodes). 

Suggest eliminating last two sentences starting at "Typically..".

Regards,
Mark Scardina
Oracle Corporation

I believe that this comment is editorial (it concerns a non-normative note). 

I believe that the first two non-normative notes in section 6.3 are carried forward from XSLT
 1.0 and contain advice which is now familiar to most experienced XSLT users. I don't think
  this sort of advice belongs in the 2.0 spec. I therefore propose to go further than you
   suggest, and delete both these notes entirely.

Please confirm whether this resolution is acceptable.

Regards,

Michael Kay
as XSL WG editor

** change applied - MHK

(Acknowledged)

SECTION 6.5: Modes

"The current mode is used when an xsl:apply-templates instruction uses
the syntax mode="#current"; it is also used by the xsl:apply-imports and
xsl:next-match instructions."

This attribute needs to be included in section K.2 as it was not in 1.0.

Regards,
Mark Scardina
Oracle Corporation

Thank you for this comment. I believe the comment is editorial, and I propose to resolve 
it by adding the following entry to the list of new features in the non-normative Appendix K.2.2:

<p>The <elb>xsl:template</elb> declaration can now declare a template rule that 
applies to several different modes; and the <elb>xsl:apply-templates</elb> 
instruction can cause processing to continue in the current mode.</p>

I would be grateful if you could confirm that this resolution is acceptable.

Thank you for pointing out the omission.

Michael Kay
as XSL WG editor

** change made - MHK

(Announced)

(Acknowledged)

SECTION 5.3.2: 

Shouldn't the XPath dynamic context include three additional components:
current-group, current-grouping-key and current-captured-substring? They
are initialized with the values of corresponding stylesheet evaluation
context components.


Regards,
Mark Scardina
Oracle Corporation

I believe that this comment (and others along the same lines) can be addressed editorially by adding
 an explanatory cross-reference from section 5.3.2 to section 2.5.2 (Additional Context Variables).

The wording I propose is:

XSLT extends the XPath function library with a number of additional functions, specifically:
 current, current-group, current-grouping-key, regex-group, document, unparsed-text, key,
  format-number, format-date, format-time, format-dateTime, unparsed-entity-uri,
   unparsed-entity-public-id, generate-id, system-property, function-available, 
   element-available. Many of these functions rely on the availability of additional
    context information beyond that in the standard XPath static and dynamic context.
     These additional context components are described in [2.5.2].

Is this an acceptable resolution of the comment?

Michael Kay
as XSL WG editor

** CHANGE NOT YET MADE - MHK

Dynamic context - see qt-2004Feb0624-01 above - closed.
   

It is acceptable to keep the text as is but add additional cross references.
 
Regards,

Mark

SECTION 4.4: Attributes Types and DTD validation

The 2nd paragraph points out backwards compatibility issues with an
example; however, it leaves the reader guessing as to a solution.
Suggest providing guidance or at minimum a reference to section K. 

Regards,
Mark Scardina
Oracle Corporation

(This was a duplicate posting identical to the original)

MHK response:

I think this is editorial. I have added more explanation to the example: 

If the value of the colors attribute is red green blue, then the expression
@colors = "red" will return true if the type annotation is xs:NMTOKENS, but
false if the type annotation is xdt:untypedAtomic. This is because the typed
value of an attribute of type xs:NMTOKENS is a sequence, in this case a
sequence of three xs:NMTOKEN values, and the equality comparison returns
true if any one of these matches the string given as the other operand.

Can you confirm that this is OK?

Michael Kay
As XSLT 2.0 editor

** ORACLE confirmed acceptance orally during 2004-03-18 telcon.

SECTION 5.3.2: Initializing the dynamic context

Please provide a better clarification of the use of the media type in
this context as it is not a mapping.

Regards,
Mark Scardina
Oracle Corporation

Will try!

This is the point that Norm Walsh brought up: since document() supports
fragment identifiers, we need to know the media type of the resource
representation retrieved by the URI, which means that the information
used by the doc() function, which simply maps the URI to a document
node, is not enough.

Michael Kay

XPath has a mapping from URI to document nodes.

For the "document" function (which allows a fragment identified) in XSLT
we also need the media type to do the "mapping".

Use phrasing like "in addition the media type associated with the URI
is available"? General agreement.

Action Mike Kay to draft text.

** DONE. Essentially, the changes proposed in response to qt-2003Dec0130-01 cover this one. - MHK 
   

SECTION 2.5: The Stylesheet Evaluation Context

The choice to name the parts of stylesheet evaluation context as
"variables" potentially can lead to a wrong interpretation due to its
use elsewhere and in XPath. A better choice would be "component" as it
is in XPath 2.0.  


Regards,
Mark Scardina
Oracle Corporation

Dynamic context - see qt-2004Feb0624-01 above - closed.
   

SECTION 5.6.1: Constructing Complex Content

Item 1:
This subsection says that attribute nodes generated by sequence
constructor instructions are prepended to the result sequence. Such a
sequence reordering could lead in some cases to serious performance
degradation. Would not an acceptable alternative be to say that
attribute nodes (if any) should be generated before any other nodes? 

Regards,
Mark Scardina
Oracle Corporation

Subsequent discussion:
http://lists.w3.org/Archives/Public/public-qt-comments/2004Feb/1054.html

The issue we were addressing is better illustrated with this example:
  <a>
   <b1/>
   <b2/>
   <b3/>
    ...
   <xsl:attribute name="c"/>
  </a>
The performance hit is that the output cannot be streamed until
xsl:attribute is processed.

Regards,

Mark

> SECTION 5.6.1: Constructing Complex Content
> 
> Item 1:
> This subsection says that attribute nodes generated by 
> sequence constructor instructions are prepended to the result 
> sequence. Such a sequence reordering could lead in some cases 
> to serious performance degradation. Would not an acceptable 
> alternative be to say that attribute nodes (if any) should be 
> generated before any other nodes? 

I've tried hard to avoid using phrases that have any temporal
connotations, i.e. any suggestion that one thing is done before doing
another thing. I think you have read a temporal meaning into the word
"prepended" that wasn't intended. There isn't actually a problem for
implementations: if you say

<a b="c">
  <d/>
</a>

then the b="c" is evaluated first to produce a sequence X containing an
attribute node, the sequence constructor <d/> is evaluated to produce a
sequence Y containing an element node, and the two sequences X and Y are
concatenated (i.e. X is prepended to Y). We should try to find a better
way of saying it, but finding the right words isn't easy. 

Michael Kay

The issue we were addressing is better illustrated with this example:
  <a>
   <b1/>
   <b2/>
   <b3/>
    ...
   <xsl:attribute name="c"/>
  </a>
The performance hit is that the output cannot be streamed until
xsl:attribute is processed.

Regards,

Mark

This seems to be caused by a misunderstanding of the text.

Action Karun to find the misleading text and Mike Kay to improve the
text.   
   

After reviewing the full text of the section, we withdraw the comment as the section meaning is clear.
 
Regards,

Mark

SECTION 2.2: Notation

Create a few examples, especially for "both", like xsl:variable, and
tell why it (they) belongs to both categories. 

Regards,
Mark Scardina
Oracle Corporation

(acknowledged)

I believe this comment is editorial.

I'm reluctant to start explaining specific features of the language in a section
 whose primary role is to define the notation used for describing the language.
  The section contains forwards links to the sections where the terms "declaration"
   and "instruction" are described in more detail, and where the various declarations
    and instructions are enumerated.

In response to your comment I would propose to add a paragraph to section 3.6,
 which describes declarations, pointing out that xsl:variable and xsl:param
  act both as declarations and as instructions, and explaining why.

Is this an acceptable resolution to your comment?

Regards,

Michael Kay
as XSL WG editor

SECTION 2.8: Stylesheets and Schemas

The subsection title becomes more precise if "XML Schemas" is used
instead of "Schemas" unless defined elsewhere. 

Regards,
Mark Scardina
Oracle Corporation

Thank you for this comment. 

I have no objection to making this editorial change (there are more important battles to fight). I therefore propose to make the change requested.

Please confirm that this is an acceptable resolution.

Regards,

Michael Kay

** Change made - MHK

(Acknowledged)

SECTION 19.1: Creating Result Tree

Suggest that this additional attribute adds meaningful functionality.
A new <xsl:result-document>  attribute:
    mode = { append, rewrite, create } 
is proposed.  This attribute specifies how to construct and serialize
the output tree.

Regards,
Mark Scardina
Oracle Corporation

SECTION 2.3: Initiating a transformation

The section does not describe how one goes about setting the base output
URI. (i.e.by xml:base attribute, by APIs or other means)

Regards,
Mark Scardina
Oracle Corporation

            
MS: XSLT doesn't describe what magic is required to determine
    where the base output URI comes from.
SB: Suggest that it be implementation-defined.

** Accepted Scott's proposal.

[MHK - spec updated 2004-05-07]
            
         

SECTION 2: Concepts

The document uses two different paradigms - sequence and tree to
describe the XSLT 2.0 semantics. There are many places where both
paradigms are applied simultaneously to explain various language
constructs.  Such a multi-paradigm approach is internally controversial
if there isn't a well-defined line of separation between them and if
there are no clear procedures how to switch from one paradigm to
another. Of course, a singleton sequence containing a node could be
viewed as a tree as well but such a dualistic approach introduces
redundant complexity to the document and if possible it is better to be
avoided.

Some examples of conceptually controversial descriptions in the
document:
Section 6.3 Applying Template Rules
In the section for <xsl:apply-templates> says that the instruction takes
as input a sequence of nodes from the source tree (actually, it could be
more than one source tree) and produces as output a sequence of items.
Later on it says that the instruction writes to the result tree (?). 

Section 9: Variables and Parameters
In the Variable value definition, value is explicitly said to be a
sequence but later in section 9.4 in the same section it also described
under what conditions the value could be a temporary tree.

Section 11.4.3 Generating Text with xsl:value-of
The description of <xsl:value-of> says that the generated text is
extracted from the source tree or by inserting value of a variable,
which is not exactly true. It is more precise to say that the text is
extracted from the sequence obtained after evaluating the select
expression or from the context item. 

Section 11.8.1 Shallow Copy
<xsl:copy> instruction is described as coping nodes from a source tree
to a result tree, which is incorrect.  It is more consistent with the
document concepts to say that the instruction copies the context item
into the result sequence. 

I believe that the clarity of the document will only benefit if:

-	All of the language construct descriptions use only the sequence
paradigm (except for describing conversion from/to sequence). This
becomes possible if the result-tree creation is viewed as a bottom-up
process (not top-down as is in XSLT 1.0). Source tree & result tree in
Section 1.2 should not be used in the context of individual
instructions.

-	Sequence to tree conversion is performed explicitly by
<xsl:result-document> and implicitly as described in Section 5.6.1
Constructing Complex Content. A new <xsl:result-document> attribute mode
= { append, rewrite, & } can be used to specify precisely how to
construct and serialize the output tree.

-	Tree to sequence conversion is performed when a transformation
is initialized (initial context node) and by document function. 

-	The concept intermediate tree and output state are redundant and
should not be used. The only extra feature the intermediate tree
provides is the implicit document node as a root of the tree. But this
minor obstacle is easily solvable if XSLT 2.0 has an  <xsl:document>
instruction.  



Regards,
Mark Scardina
Oracle Corporation

This is a very interesting comment and we will obviously have to discuss
it. However, I *think* that the weaknesses you point out are mainly
editorial rather than technical. If I read you correctly, you're not
quarelling with the basic processing model, whereby trees are
constructed bottom up by building a sequence and then using this to form
the children of a new element or document node; what you are saying is
in large measure that the specification still contains relics of the
older top-down processing model that we need to get rid of.

Some specific responses:

> Section 6.3 Applying Template Rules
> In the section for <xsl:apply-templates> says that the 
> instruction takes as input a sequence of nodes from the 
> source tree (actually, it could be more than one source tree) 
> and produces as output a sequence of items. Later on it says 
> that the instruction writes to the result tree (?).

Yes. This is lazy terminology. The Note in section 2.1 is effectively an
apology for the loose use of the words "source tree" and "result tree"
throughout the document, but we should remove the loose wording rather
than apologizing for it. (My main concern in doing this has been how to
keep the document understandable.) Anything that refers to instructions
"writing to the result tree" is a hangover from the 1.0 spec and needs
to be changed.

** the use of the terms "result tree" and "final result tree" has been
tightened up in draft U - MHK
 
> 
> Section 9: Variables and Parameters
> In the Variable value definition, value is explicitly said to 
> be a sequence but later in section 9.4 in the same section it 
> also described under what conditions the value could be a 
> temporary tree.

In this case I think both statements are true: a temporary tree is
identified by a document node, and the document node is a singleton
sequence containing one node. But the apparent contradiction needs to be
explained better, and the terminology tightened up.

** added clarification to 9.4 in draft U - MHK

> 
> Section 11.4.3 Generating Text with xsl:value-of
> The description of <xsl:value-of> says that the generated 
> text is extracted from the source tree or by inserting value 
> of a variable, which is not exactly true. It is more precise 
> to say that the text is extracted from the sequence obtained 
> after evaluating the select expression or from the context item.

Yes.  

** sentence reorganized in draft U to make it clearer that these are examples. - MHK
> 
> Section 11.8.1 Shallow Copy
> <xsl:copy> instruction is described as coping nodes from a 
> source tree to a result tree, which is incorrect.  It is more 
> consistent with the document concepts to say that the 
> instruction copies the context item into the result sequence.

Yes. 

** offending phrases deleted in draft U - MHK
> 
> I believe that the clarity of the document will only benefit if:
> 
> -	All of the language construct descriptions use only the sequence
> paradigm (except for describing conversion from/to sequence). 
> This becomes possible if the result-tree creation is viewed 
> as a bottom-up process (not top-down as is in XSLT 1.0). 
> Source tree & result tree in Section 1.2 should not be used 
> in the context of individual instructions.

Yes.

** all uses of "result tree" reviewed, and removed where appropriate - MHK

> 
> -	Sequence to tree conversion is performed explicitly by
> <xsl:result-document> and implicitly as described in Section 
> 5.6.1 Constructing Complex Content. 

And also, of course, by instructions that invoke 5.6.1, such as
xsl:element and xsl:copy.

> A new 
> <xsl:result-document> attribute mode = { append, rewrite, & } 
> can be used to specify precisely how to construct and 
> serialize the output tree.

I think this suggestion is orthogonal to the rest of the comment. I can
see how it would be useful to say action=new|overwrite on
xsl:result-document to control whether the system is allowed to
overwrite an existing file. I'm not so comfortable with append, because
(a) it's not clear what you get when you append one serialized XML
document to another, and (b) the order of sub-documents in the output
would be implementation-dependent.

** no action on this one, which duplicated another comment that was rejected. - MHK 

> 
> -	Tree to sequence conversion is performed when a transformation
> is initialized (initial context node) and by document function.

I'm not sure I understand this comment.  
> 
> -	The concept intermediate tree and output state are redundant and
> should not be used. The only extra feature the intermediate 
> tree provides is the implicit document node as a root of the 
> tree. But this minor obstacle is easily solvable if XSLT 2.0 
> has an  <xsl:document> instruction.  
> 

The purpose of the "intermediate/final" distinction and output state is
to limit the extent to which xsl:result-document can cause unpredictable
side-effects. I'm not sure in my own mind whether the side-effect
problems are really grave enough to justify this machinery.

Michael Kay

            
 
qt-2004Feb0559-01
ORA-XS-313-C: Comments about the XSLT 2.0 concepts.

Status: Mike to use this comment and make editorial changes, to clean
up use of XSLT 1.0 text.

** DONE - mainly a clean-up of the use of the terms "result tree" and "final result tree". See
annotations attached to previous MHK response, above.

            
         

SECTION 2.1: Terminology

The definition of XSLT processor becomes more precise if "using an XSLT
stylesheet" is added. 

Regards,
Mark Scardina
Oracle Corporation

            
** Accept change proposed in comment.

[MHK: change made 2004-05-07]
            
         

SECTION 2.3: Initiating a Transformation

In Sections 2.3, 2.5 and later, would be more consistent to use
#undefined for the initial value of evaluation context components
instead of mixing unset and undefined. 

Regards,
Mark Scardina
Oracle Corporation

            
MS: Would like to see "undefined" be used consistently.
    "unset" seems to imply a state, where "undefined"
    seems stateless.

** Accept proposal to use "undefined" rather than "unset".

[MHK: change made 2004-05-07]
            
         

SECTION 5.6.1: constructing complex content

"with a with a single space (#x20)" should be single "with a".

Regards,
Mark Scardina
Oracle Corporation

 
MHK response:
 
Thanks for the comment. I have corrected this typo, and shall assume your
tacit agreement with this response.
 
Michael Kay
As XSLT 2.0 editor

 

XSLT 2.0 recommendation states "XSLT 2.0 provides no facility to construct unparsed entities within a tree"

I think this is a mistake.

Problem Summary:

When transforming using intermediate formats I frequently find that entity references are resolved 
too early. One solution would be to use a catalog to switch entity sets dynamically, but don't know
 of such on my platform.

Scenario, Problem details

My situation is as follows:

I have a TeX based parsing package which has problems with the '$' character. So I use the
 $ entity, but then I find that HTML output doesn't resolve this entity and I find 
 the literal $ in my HTML output.

To work around this problem I use a <dollar/> element and have to put the following in 
my stylesheet:

  <xsl:template match="dollar">$</xsl:template>

This is a problem for every stylesheet that starts from this source, and I find the 
process both confusing and inelegant.

Solution, Request

What I would like is a new parameter, so that I could write the following, which would 
remove a lot of headaches transforming between multiple output DTDs. 

  <xsl:template match="text()">
     <xsl:value-of select="." unparsed-entity-references="yes"/>
  </xsl:template>

So much better with 'unparsed-entity-references' at the head of the stylesheet. 
Then I can use <!ENTITY dollar "&#x0024;"> <!-- DOLLAR SIGN -->
in my local DTD, and pass on the entity reference to intermediate DTDs.

Best wishes,
Christopher Tipper

qt-2004Feb0691-01: request, unparsed-entity-references
CLOSED, 
actoin: mk to tell him where to get help.
** Action DONE, MHK
      

Mike Kay wrote over on xsl-list

  My own experience of migrating real stylesheets has been that there have
  been very few problems, and that they have generally related to use of
  extensions rather than to facilities in the W3C specs. If anyone does
  have any negative experiences of migration, I will be very interested to
  hear them (ideally, send them direct to the public-qt-comments@w3.org
  list).


I just tried running a (set of) XSLT transformation (around 13000 lines
of xslt 1.0) over a sample document using saxon 7.8, which implements
most of the current draft. I have not yet compared the results to see if
they are the same or equivalent (which is hard and would require visual
checking) I am here just concentrating on cases where errors are raised
where previously there were none.

XSLT2 "backward compatibility"  failed to produce a compatible result
(or in fact, any result at all) due to a dozen or so instances of the
same error.

It is now an error to pass parameters to named templates if they are not
declared in the template.

I strongly believe that this should _not_ be an error in BC mode.

Reviewing the cases that required change:

one or two were "dead" parameters that had been used in earlier
versions, but no longer appeared to be used. So their presence
did no harm, but did no good either. Being warned of this might be seen
as a good thing, but since it was a fatal error that stopped compliation
of the stylesheet this would have been rather an expensive thing to
test/debug and basically would mean that a production system using xsl1
will probably need to stay using xslt1 as long as possible. It might seem
that this is a trivial change to make run on xslt2 (just remove the
offending xsl:with-param) but in fact the hard part is distinguishing
this class (which is a minority in my case) from the other class of
constructs that triggered this error described below.

The majority case was due to the fact that we produce two sets of
documents (describing C and Fortran interfaces, as it happens) from the
same source. The set up is the usual one, two top level stylesheets each
importing a common one.

However there are many parts of the transformation that are different in
the two cases and need to be paramaterised diferently. The common code
calls a named template with any parameters that might be useful in
either interface. This now generates an error.

A typical case is the named template

<xsl:template name="optparam-test">
 <xsl:param name="id"/>
 ....

which does something in the C interface but this is a no-op in the
Fortran interface so that has (had)

<xsl:template name="optparam-test"/>

In XSLT2 this will have to be defined to take the same parameters (just
id in this case) as the C interface.

It is not clear to me that this requirement is necessarily a good thing
(even in native xslt 2 mode) however I don't strongly object to it in
2.0 mode. As I say above, it did catch a couple of cases of dubious
coding. However there is a real temptation to respond to the error
message by commenting out the xsl:with-param only to find later that you
have broken some other stylesheet that was expecting that parameter to
be passed.


This change is too much for backward compatibility mode.



Having resolved all these parameter passing problems the stylesheeet
then compiled and produced just one warning (twice).

Warning: at xsl:for-each on line 3403 of file:/c:/engine-cvs/doc/xsl/libdoc-c-xml.xsl:
  Less-than and greater-than comparisons between strings have changed since XPath 1.0

 <xsl:variable name="a" select="mn[1]/text()"/>
 <xsl:variable name="b" select="mn[2]/text()"/>
 <xsl:for-each select="$enum[@fname=$fpname]/v[$a &lt;= @f and @f &lt;= $b]">

which is checking that three "numbers" obtained from the source files
satisfy a constraint that one lies between the other two.

Is it really necessary for this to break in BC mode?
Is it not possible for the mapping of &lt;= to the underlying F&O
operators is changed in BC mode to more closely match the behaviour in
1.0? While this is annoying it is actually less trouble to fix than the
previous error, especially in this case, where the node sets such as @f
in the expression really are only going to return one node  so I would
just need to add a couple of instances of number() (I hope:-)
However if tehre are cases where the implicit existential quantification
are used, it will be tricky for an end user to get right (easier for the
system, I would have thought).

While I do appreciate the facility to switch between native and BC mode
on specific elements within the stylesheet,  I believe that verion="1.0"
on an xsl:stylesheet (or outer most element of a simplified stylesheet)
should be treated differently: the stylesheet should be processed by an
XSLT 1.0 processor, or an error raised if the processor does not support
1.0. 

David

         Summary: there was an extensive discussion of the merits of this change.

Proposal:  Error XT0680 does not apply if backwards compatibility
           behaviour is enabled for the xsl:call-template.

** Accepted proposal.

[MHK: text updated 2004-05-07]
            
         

David,

     This is the response to your comment on the XSLT 2.0 Last Call 
Working Draft.  Your comment can be found in the following message:

http://lists.w3.org/Archives/Public/public-qt-comments/2004Feb/0856.html

(Issue qt-2004Feb0856-01)

     Thank you for your comment.

     The XSL Working Group discussed your comment, and agreed that it 
would not be acceptable for it to be, in all circumstances, a static error 
to specify an xsl:with-param in an xsl:call-template if the named template 
did not have an xsl:param with the same name.  As you pointed out, the 
effect on any existing XSLT 1.0 stylesheets that relied on the fact that 
no error would be produced would be too great.

     However, the consensus of the working group was also that this 
feature of XSLT 1.0 was a likely source of bugs, as simple typographical 
errors in the name specified for an xsl:with-param could easily go 
undetected.  Therefore, the working group decided that ERR XT0680 (defined 
in Section 10.1.1) should be produced only if backwards compatible 
behavior is not in effect for the xsl:call-template instruction in 
question.

     As that is the proposal you made in your comment, I trust the 
decision will be acceptable to you.  May I ask you to confirm that?

Thanks,

Henry [On behalf of the XSL Working Group]
------------------------------------------------------------------
Henry Zongaro      Xalan development
IBM SWS Toronto Lab   T/L 969-6044;  Phone +1 905 413-6044
mailto:zongaro@ca.ibm.com

>      As that is the proposal you made in your comment, I trust the 
> decision will be acceptable to you.  May I ask you to confirm that?

Yes that's fine.

The original message also contained an unrelated comment about the use
of < on untyped data. Mike Kay started a new thread on that, following
my message, so i assume that that will be handled under that heading?

David

POSTSCRIPT: the use of < on untyped data was an XPath issue, and overlapped another open
issue. The rules handling < in backwards compatibility mode were eventually changed, so that
"backwards compatibility means what it says". - MHK

Hi, 
i want ask you to add next feature in XSLT 2.0 spec.,
I want to use xsl:parameter in select attribute of (xsl:value-of, xsl:apply-template etc...) 
 where xPath expression described in xsl:parameter.
For example something like this
<xsl:parameter name="xPath">/rootnode/childnode[@a='111']/etc</xsl:parameter>
<xsl:value-of select="GenerateXPathFromParameter($xPath)" /> 

I want to xsl:value-of in this situation works as 
<xsl:value-of select="/rootnode/childnode[@a='111']/etc" /> 

Please answer me, what do you think about.

Sorry for my english,


PS:
It's needed for next situation: for example 
i have some configuration file, in which
some references to another xml document are presented, i want in xslt 
using configuraton file get nodes from xml, using xPath references described in Config.xml file.

MHK response:
Thank you for the comment. If I read it correctly, you are asking for
something similar to the dyn:evaluate() extension in EXSLT (see
www.exslt.org) or the similar facilities in Saxon and Xalan. Perhaps you
can confirm this?

The XSL WG decided in the past not to include this feature in XSLT 2.0.
I think the main concerns were (a) from people developing XSLT compilers
and processors designed to execute in a very small footprint, that they
didn't want to have an XPath interpreter around at run-time, and (b)
that it would be difficult to define the evaluation context in detail
(for example, namespaces, access to variables, and so on). 

Since you have raised this as a last call comment on the specification,
we will review our decision to exclude this feature.

Regards,

Michael Kay

Response:
Thank you for the answer!!!,
yes  i've asked about functionality dyn:evaluate().

Ivan Starkov.

         Summary: members of the WG recognized that this functionality was useful,
         but also that it would be very difficult to provide in some environments. 
 
            
         

According to the discussion in [1], there seems to be a problem with the
type that the preserve validation mode assigns to the new wrapper
element.

 

The type associated with a newly constructed element that contains
information that has preserved its previous type should not be
xdt:untypedAny, since this type guarantees that any of its descendent
children, atributes and values are also untyped. If you preserve the
type information, you are obviously violating that type safety
assumption. The solution (pending approval of action item TAMPA-02) is
to instead type such elements as being of type xs:anyType (or whatever
dynamic type name will be chosen during resolution of action item
TAMPA-02 to indicate a partially validated element content).

 

Best regards

Michael [Rys]

[1]
http://lists.w3.org/Archives/Public/public-qt-comments/2004Feb/0237.html

            

Summary: the proposed change was discussed and agreed.


         

Issue qt-2004Feb1007-01

At its meeting on 13 May 2004 the XSL WG agreed to accept your proposal that
elements constructed with validation="preserve" should have a type
annotation of xs:anyType rather than xdt:untyped [or xdt:untypedAny as it is
in the current published draft].

I assume this meets with your approval.

Michael Kay
for the XSL WG

Yes, thanks.

Michael

Hello,

     Following are comments on XSLT 2.0 that we believe to be editorial in 
nature.

------------------------------------------------------------------

Global Editorial

Different elements exhibit different behaviour with respect to import 
precedence.  These differences are frequent sources of confusion. 
Rationale for the particular behaviour of each element should be provided 
in order to aide readers.

------------------------------------------------------------------

Section 1.1

The fourth paragraph states that "XSLT is used for a wide range of 
XML-to-XML transformation tasks, not exclusively for formatting and 
presentation applications."

Although this is introductory, it might be worth noting that it is also 
used for a range of XML-to-non-XML transformation tasks as well.  For 
example, DOM3 test generation.

------------------------------------------------------------------

Section 2.3

The fifth bullet in the bulleted list refers to the "default mode".  This 
term should be defined somewhere with a termdef.

------------------------------------------------------------------

Section 2.4

The bulleted list of instruction elements should include xsl:param 
(probably with "Instructions that declare variables").  If the list isn't 
intended to be exhaustive, that should be stated or it should be removed 
competely.

------------------------------------------------------------------

Section 2.5.1

The paragraph that precedes the definition of singleton focus ("Sometimes 
the focus is based on a single node.") doesn't flow very well from the 
paragraph that precedes it.  As it doesn't add anything, it should be 
removed.

------------------------------------------------------------------

Section 2.9

In the paragraph before "Example: Errors in Constant Subexpressions", the 
scope of the "constant expression evaluation" subphase must be 
sufficiently well-defined.  A proper specref in place of "XPath 
specification states" is required, and should consider making "evaluate" 
into a termref.
------------------------------------------------------------------

Section 2.9

The paragraph before "Example: Errors in Constant Subexpressions" 
indicates that "any error occurs during [constant subexpression] 
evaluation. . .  must be held back until the evaluation phase, and 
signaled only if the XPath expression is actually evaluated."

It needs to be made clear that if the implementation can determine that 
the error would always be reported, that it can do so, as described in the 
preceding paragraph.  The wording of the last paragraph might be taken to 
override the permission provided by the preceding paragraph.

------------------------------------------------------------------

Section 3.3

In the first paragraph, it needs to be made clear that although the 
presence of the extension attribute does not affect the result tree, the 
namespace declaration for that extension will affect the result - in 
particular, the namespace declaration might be present in the result.

------------------------------------------------------------------

Section 3.6

The second paragraph of the note in this section introduces the concept of 
"entry modules".  Define "entry module" or add a good example.  The 
meaning isn't necessarily immediately clear.

------------------------------------------------------------------

Section 3.8

The second sentence of the third paragraph contains a link to XPath with 
the label "Section".  This appears to be a documentation build error of 
some sort.

------------------------------------------------------------------

Section 4.2

It would probably be helpful to point out to users here the potential 
pitfall of using xml:space='preserve' in the presence of xsl:attribute 
elements - it might result in a whitespace text node being created as a 
child of an element before an attribute node is generated.

------------------------------------------------------------------

Section 4.3

The second paragraph reads, "The stripping process takes as input a set of 
element names whose child whitespace text nodes are to be preserved."  How 
that set is constructed is only described further on, beneath the syntax 
diagrams for xsl:strip-space and xsl:preserve-space.

That separation makes the quoted sentence seem confusing.  One easily 
makes the mistake that this is actually referring to the pair of 
whitespace-separated lists of NameTests that appear as the values of the 
elements attributes in xsl:strip-space and xsl:preserve-space.

------------------------------------------------------------------

Section 4.4

The title "Attributes Types and DTD Validation" should be "Attribute Types 
and DTD Validation" or "Attributes' Types and DTD Validation".

------------------------------------------------------------------

Section 4.4

In the second paragraph, it would be helpful to provide a little more 
detail about how the equality comparison works.

------------------------------------------------------------------

Section 5.6.1

The second item in the numbered list, indicates that "Special 
considerations apply to two atomic types for which casting to xs:string is 
not possible. . . ."  However, there is only one such type.

------------------------------------------------------------------

Section 6.4

The first item in the numbered list states "First, all matching template 
rules that have lower import precedence than the matching template rule or 
rules with the highest import precedence are eliminated from 
consideration."

The wording of this is ambiguous.  It can be read as "First, (all matching 
template rules that have lower import precedence than the matching 
template rule) or (rules with the highest import precedence) are 
eliminated from consideration."

A better wording might be "First, only the matching template rule or rules 
with the highest import precedence are considered. Other matching template 
rules with lower precedence are eliminated from consideration."  The 
second item could then be reworded as "Next, of the remaining matching 
rules, only those with the highest priority are considered. Other matching 
template rules with lower priority are eliminated from consideration."

------------------------------------------------------------------

Section 7

In the second paragraph, the use of the term "sorted sequence" is 
potentially confusing, as it might refer to a sequence that hasn't been 
sorted at all.

We would suggest changing " the input sequence is sorted to produce a 
sorted sequence" to "is sorted before being used", and using the term 
"input sequence" instead of "sorted sequence" everywhere else.

------------------------------------------------------------------

Section 7

The lead-in to the bulleted list reads "The sequence constructor is 
evaluated with the focus set as follows".

This might read better reworded as "For each item in the sorted sequence, 
the sequence constructor is evaluated with the focus is set as follows:"

------------------------------------------------------------------

Section 9.4

The fourth sentence of the first paragraph uses the term "owned by".  This 
term is not defined nor is it used anywhere else.

Suggest changing "evaluating the sequence constructor owned by the 
variable-binding element" to "evaluating the contents of the 
variable-binding elment as a sequence constructor".

------------------------------------------------------------------

Section 9.4

In the first sentence of the second paragraph, there is a reference to 
Data Model, but it's not clear what one is being directed to see there. 
The reference should be placed after the words "The base URI of a node".

------------------------------------------------------------------

Section 9.4

In the example "Example: Two-Phase Transformation", it probably will not 
be clear to a novice reader that the imported stylesheets in the example 
will define templates only for the particular modes.

------------------------------------------------------------------

Section 9.4

The note suggests it is a good idea to use modes when transforming 
temporary trees.  It should be clarified that that's only necessary if 
different templates actually need to be applied.

------------------------------------------------------------------

Section 10.1.2

In the xsl:number instruction in "Example: Using Tunnel Parameters", 
'format="{$format}"' should be 'format="{$equation-format}"'.

------------------------------------------------------------------

Section 10.3

It is easy for a reader to make the mistake that the override attribute 
can be used to prevent a stylesheet function from overriding another 
stylesheet function with the same expanded QName with lower import 
precedence.  It should be made very clear that it can only override 
"built-in" functions.  That could include renaming the attribute to 
something like "override-builtin-functions".  An example illustrating the 
behaviour would also be appropriate.

------------------------------------------------------------------

Section 10.3

The bulleted list describing which stylesheet functions are included in 
the in-scope functions is somewhat confusing.

It would probably be easier to read if reworded to describe the intended 
effect - for example, "A stylesheet function definition suppresses any 
other stylesheet function defintions with the same name and arity that has 
lower import precedence.  It is added to the in-scope functions, unless 
the override attribute has the value "no" and there is a 
processor-provided function of the same name and arity, in which case that 
function will be included in the in-scope functions."

------------------------------------------------------------------

Section 10.3

In the second note, which describes the override attribute, it might not 
be clear that the attribute can override extension functions that might be 
provided by the user, not just functions that are provided by the 
implementation.

------------------------------------------------------------------

Section 11.1.2

The fifth sentence of the third note states, "One consequence of this is 
that these attributes should not be written as attribute value templates: 
although an XSLT processor will understand this notation, the XML parser 
will not."

Making a normative statement with the RFC term "should not" isn't 
appropriate in a note.  Either this needs to be stated normatively or use 
of the RFC "should not" should be avoided.

------------------------------------------------------------------

Section 11.1.2

The third paragraph of the third note states "None of these attributes 
will be generated in the result tree unless the stylesheet writes them to 
the result tree explicitly, in the same way as any other attribute."

It might not be clear to a user why he or she might have thought these 
attributes would have been generated automatically.  It might be helpful 
to describe the fallacious reasoning that this sentence is trying to 
correct.

------------------------------------------------------------------

Section 11.1.2

Error XT0805 is "It is a static error if an attribute on a literal result 
element is in the XSLT namespace, unless it is one of the attributes 
explicitly defined in this specification."

It would be helpful to point out to readers that they might need to use 
namespace aliasing or xsl:element/xsl:attribute if they really need to 
create such attributes in the XSLT namespace.

------------------------------------------------------------------

Section 11.1.3

It is odd that a feature like exclude-result-prefixes is defined here, 
rather than in its own section.  It might be better as a subsection in the 
Namespace fixup section.

------------------------------------------------------------------

Section 11.1.3

A sentence in the third bullet states "It is a static error if there is no 
namespace bound to the prefix on the element bearing the 
[xsl:]exclude-result-prefixes attribute."

The words "prefix on the element" make it sound like this is talking about 
the prefix of the element.  We suggest changing "on the element" to "by 
the element".

------------------------------------------------------------------

Section 11.1.3

The third bullet makes reference the "The default namespace (as declared 
by xmlns)".  It might be unclear to some readers whether default namespace 
refers to a namespace declared using xmlns="uri" or the default - no 
namespace.  It would be worthwhile defining the term in one place, and 
including termref's to it.

This same comment applies to the second paragraph after the first bulleted 
list in 11.1.4, and in the paragraph in Section 11.2 that defines error 
XT0830.

------------------------------------------------------------------

Section 11.1.3

The last paragraph of the example "Example: Excluding Namespaces from the 
Result Tree" begins "If the stylesheet is changed so that the literal 
result element has an attribute b:bar="3", then the element in the result 
tree will typically have a namespace declaration xmlns:b="b.uri", although 
the processor is free to choose a different namespace prefix if it 
wishes."

This should be reworded to indicate that some namespace declaration for 
the namespace must be available, rather than appealing to the typical 
behaviour.
------------------------------------------------------------------

Section 11.1.3

The material that appears in the last paragraph of the example "Example: 
Excluding Namespaces from the Result Tree" would be better placed in 
Section 5.6.3.
------------------------------------------------------------------

Section 11.1.4

The second note in this section states, "The processor still has a free 
choice of prefixes when generating element and attribute names in the 
result tree, but it will normally use the result-prefix since that prefix 
will already be declared in the result tree."

As this is implementation dependent, the note shouldn't refer to the 
"normal" behaviour.  If we want to make a normative statement, that can't 
be handled editorially.

------------------------------------------------------------------

Section 11.1.4

In the example box, the paragraph before the second stylesheet states in 
part, "however, the rules guarantee that there will be a namespace node 
that binds the prefix xsl to the URI http://www.w3.org/1999/XSL/Transform, 
which makes it safe to use the QName xsl:version in the content of the 
generated stylesheet."

It might not be clear to the reader which rules guarantee this.  That 
should be explicitly stated.

------------------------------------------------------------------

Section 11.1.4

It might be worthwhile to add a note that describes the merits of using 
xsl:attribute and xsl:element over using namespace aliasing.  For example, 
"xsl:element and xsl:attribute (see following sections) can also be 
practical solutions for the tasks commonly addressed via namespace 
aliasing. They have the advantages of being more direct and of permitting 
more explicit "hinting" about the desired prefix, at the expense of being 
more verbose. Users may wish to consider both approaches and select the 
one which best suits their needs."

------------------------------------------------------------------

Section 11.2

In the description of the recovery action for Error XT0820, it might be 
worthwhile to add that the xsl:element is replaced by its children, in 
case the effect of the recovery isn't clear to all readers.

------------------------------------------------------------------

Section 11.2

The recovery action for Error XT0820 is potentially surprising.  Some 
rationale for the recovery action might be appropriate.

------------------------------------------------------------------

Section 11.2

The recovery action for XT0830 is "to ignore the prefix part of the 
lexical QName, with the effect that the new element will be in the default 
namespace."  It is not clear whether the element is in the default 
namespace of the result or the default namespace of the stylesheet.

------------------------------------------------------------------

Section 11.3

Error XT0840 states "It is a static error if the select attribute of the 
xsl:attribute element is present unless the element has empty content." 
Section 5.6 deals with stripping of whitespace nodes in this situation, 
but it might make things more clear to say "unless the element has empty 
content after whitespace nodes have been stripped from the stylesheet."

------------------------------------------------------------------

Section 11.4.2

In the second paragraph, the phrase "either a single node, the newly 
constructed text node, or an empty sequence" might be taken to present 
three choices rather than two.  It should be rephrased as "either the 
newly constructed text node or an empty sequence."

------------------------------------------------------------------

Sections 11.4.2 and 11.4.3

These sections should state that the text created by xsl:text or 
xsl:value-of instructions might be merged with other adjacent text into a 
single text node.  This is only stated explicitly in the case of literal 
text nodes in 11.4.1.

------------------------------------------------------------------

Section 11.5

The note begins "This means that xsl:processing-instruction cannot be used 
to output an XML declaration."  It is not clear what the antecedent of 
"this" is.  Is it the rule in XT0890 or the fact that xsl:attribute cannot 
be used to construct the pseudo-attributes of a processing instruction?

------------------------------------------------------------------

Section 11.6

The sections on xsl:element and xsl:attribute state "The effective value 
[of the namespace attribute] should be a URI reference.  It is not an 
error if the string is not a syntactically legal URI reference."  A 
similar statement is required for xsl:namespace.

------------------------------------------------------------------

Section 11.6

The second paragraph of the first note in this section states that adding 
a namespace node to the result tree "does, however, constrain the choice 
of prefixes when namespace fixup is performed."

The word "does" should be changed to "might" - adding such a namespace 
node could also increase the number of choices available or have no effect 
on the choice.

------------------------------------------------------------------

Section 11.8.1

The second note states "but if namespaces are used in the content of the 
attribute. . . then it is the responsibility of the stylesheet author to 
ensure that suitable namespace declarations are added to the result tree."

This should really begin "but if namespace prefixes are used. . . ."  A 
namespace URI could be used inside of an attribute without requiring any 
namespace declaration.

------------------------------------------------------------------

Section 13.1.2

The second paragraph uses the term "converted" twice.  This should be 
"cast" to avoid any confusion about the meaning of the term.

------------------------------------------------------------------

Section 13.1.3

The paragraph after the second note indicates that the lang and case-order 
attributes "identify a suitable collation".  It should be noted that for 
any particular combination of lang and case-order, there may be more than 
one suitable collation.

------------------------------------------------------------------

Section 14.3

The last sentence in the second paragraph states that "A group is never 
empty."  The fifth paragraph begins with the sentence "If the population 
is empty, the number of groups will be zero."  These two related sentences 
should probably appear closer to one another.

------------------------------------------------------------------

Section 14.3

In the definition following XT1090, there is no term that is in bold type 
that is being defined.  Is this defining "grouping key"?

------------------------------------------------------------------

Section 14.3

The definition of "processing order" ends prematurely.  To complete the 
definition, the two sentences that follow should probably be included in 
the definition.  Otherwise, the definition should be reworded in order to 
stand alone.

------------------------------------------------------------------

Section 14.3

The title of the example box "Example: Sorting Groups in order of their 
Grouping Key" isn't accurate - it includes two examples, only one of which 
uses a grouping key.

------------------------------------------------------------------

Section 15.1

The paragraph following XT1150 begins "The xsl:analyze-string instruction 
starts at the beginning of the input string and attempts to find the first 
substring that matches the regular expression."

It doesn't seem appropriate to talk about this particular complexity of 
regular expression matching, out of all the other complexities discussed 
in the F&O. A reference to F&O would probably be more appropriate.

------------------------------------------------------------------

Section 15.2

In the definition of "current captured substrings", "parenthized" should 
be "parenthesized".

------------------------------------------------------------------

Section 15.2

The behaviour of the regex-group function is not sufficiently specified 
when it is used within xsl:non-matching-substring and outside of 
xsl:analyze-string - in particular, how is an argument value of zero 
handled in those situations?  It's not clear whether the matching string 
is considered to be considered to be a one of the current captured 
substrings, and so, part of the sequence, which would imply that 
regex-group(0) should return the zero-length string in those situations, 
or whether it is still "the same as the value of . (dot)" in those 
situations.

------------------------------------------------------------------

Section 16.1

The last rule in this section begins "The effect of these rules. . . ." 
These rules have more than one effect; this should be "One effect of these 
rules. . . ."

------------------------------------------------------------------

Section 16.2

The second paragraph indicates that "The URI must contain no fragment 
identifier. . . ."  Presumably this is because the text has no known 
structure.  It would be helpful to state the rationale behind the 
restriction.

------------------------------------------------------------------

Section 16.2

The paragraph following the first note, states "This encoding is used to 
translate the contents of the file into a string."  More accurately, it 
specifies a default unless file-specific information is available as 
described further on.

------------------------------------------------------------------

Section 16.3.2

The paragraph following the bulleted list describes the interpretation of 
the current function when it appears in match or use in xsl:key.  This 
really belongs in 16.3.1 - though the wording might be complicated by the 
fact that it can't refer to the node N that is being considered.

------------------------------------------------------------------

Section 16.5.2

The seventh paragraph reads as follows:

<<
The choice of the names and abbreviations used in any given language is 
implementation-defined. For example, one implementation might abbreviate 
July as Jul while another uses Jly. In German, one implementation might 
represent Saturday as Samstag while another uses Sonnabend. 
Implementations may provide mechanisms allowing users to control such 
choices.
>>

It should be explicitly stated that mechanisms that allow users to control 
such choices must not be in the form of additional, implementation-defined 
presentation modifiers.

------------------------------------------------------------------

Section 16.6.5

The sentences before and after the note in this section are related, and 
should probably be placed in a single paragraph, rather than being 
separated by a note.

------------------------------------------------------------------

Section 18.1

The first paragraph of this section needs to deal with the fact that the 
stylesheet function with highest import precedence might have specified 
the override attribute with a value of "no".  We understand that the 
reference would be to the extension function in this case.

------------------------------------------------------------------

Section 18.2.2

The first paragraph states, "The element-available function can be used 
with the xsl:choose and xsl:if instructions to explicitly control how a 
stylesheet behaves if a particular extension instruction is not 
available."

The element-available function applies to instructions in the XSLT 
namespace as well as to extension instructions.  The quoted sentence needs 
to be reworded.

Given that the function applies to more than just extension instructions, 
perhaps it should be moved to another section.

------------------------------------------------------------------

Section 19

In the second paragraph, suggest changing "may be created" to "can be 
created", to avoid confusion with the RFC term.

------------------------------------------------------------------

Section 19

The fourth paragraph begins "A result tree has a URI."  We would suggest 
this be changed to "A result tree is assigned a URI when it is created" or 
perhaps "A result tree is assigned an absolute URI when it is created."

------------------------------------------------------------------

Section 19

The first note begins "The URI of the result tree is not the same thing as 
the URI of its serialized representation. . . ."  The words "is not the 
same thing" are too strong; perhaps, it should be "is not necessarily the 
same thing"

------------------------------------------------------------------

Section 19

The last sentence of the first note begins "As long as it satisfies 
requests. . . ."  It is not clear what the antecedent of "it" is in this 
case.  Perhaps this should be "As long as the API satisfies requests. . . 
."

------------------------------------------------------------------

Section 19

All this description of how the URI that is associated with the result 
tree might be utilized by an API seems like it belongs with the 
description of the href attribute in section 19.1, as it specifies the 
URI.

------------------------------------------------------------------

Section 19

In the last note, the phrase "is unrelated" is too strong.  We would 
suggest "may differ from"

------------------------------------------------------------------

Section 19.1

The fourth paragraph following XT1460 states that "An implementation that 
does not support the serialization of result trees. . . must provide the 
application with some means of access to the (un-serialized) result tree, 
optionally using its URI to identify it."  However, the fourth paragraph 
of Section 19 states that "If the implementation provides an API to access 
result trees, then it must allow a final result tree to be identified by 
means of this URI."

The two statements differ as to whether an API must allow result trees to 
be identified by URI.

------------------------------------------------------------------

Section 19.2

A brief summary of the distinction between the validity and type 
attributes -- validity tests for any valid type, while type insists on 
validating against a specified type, if I'm reading this correctly -- 
would tremendously improve readability of this section, by setting context 
and giving the reader some guidance as to the differences in syntax and 
semantics.

------------------------------------------------------------------

Section 19.2.1

The first and second subbullets of the third bullet in the first bulleted 
list indicate that in certains circumstances the "transformation fails."

It would be helpful to provide a link to the error that is reported in 
each case, because the definitions of the definitions of those errors are 
so far-removed.

------------------------------------------------------------------

Section 19.2.1

The third subbullet of the the third bullet in the first bulleted list 
states that "The schema components used to validate an element or 
attribute may be located in any way permitted by [XML Schema]."  The word 
"permitted" is too strong; the section of XML Schema that is cited just 
describes a number of possibilities, without any restrictions.  Perhaps 
"described" would be a better word.

Where the remainder of the bullet indicates that the processor might have 
implicit knowledge of a namespace or may use a schemaLocation to locate 
schema components, it should be made clear that those are just two 
possibilities - not an exhaustive list.

------------------------------------------------------------------

Section 19.2.1

The third bullet of the second bulleted list states, "If the element or 
attribute is not considered valid, the transformation fails."  For 
clarity, the word "valid" should be changed to "a valid instance of the 
specified type".

------------------------------------------------------------------

Section 19.2.1

The first part of this section is specific to [xsl:]validation; the second 
part is specific to [xsl:]type.  It is not clear whether the paragraphs 
and bulleted lists following the last note in this section only apply if 
the [xsl:]type attribute is specified.

------------------------------------------------------------------

Section 20

The paragraph following XT1560 states that "The values of attributes are 
defaulted after the xsl:output elements have been merged. . . ."  However, 
if no method attribute is specified, not all of the default attribute 
values are necessarily known after merging.

------------------------------------------------------------------

Section 20

The third bullet from the end of the list states, "The 
undeclare-namespaces attribute is relevant only when producing output with 
method="xml" and version="1.1"."  This should probably be rephrased to 
allow for future versions of XML.

------------------------------------------------------------------

Section 21

The note in this section refers to the static typing feature.  Some 
normative statement about this feature should be provided - perhaps in 
section 2.8

------------------------------------------------------------------

Section 21.1

The second note indicates that a processor might ignore non-trivial type 
annotations from PSVI in order to construct a data model that conforms to 
the requirements of a basic XSLT processor.  It should also be noted that 
the data model cannot be constructed from Infoset as described in the Data 
Model document, as that can result in attributes with types that aren't 
permitted for a basic XSLT processor - such types would similarly have to 
suppressed in order to construct a data model that conforms to the 
requirements of a basic XSLT processor.

------------------------------------------------------------------

Appendix F

Whether a processor supports the XML 1.0 or 1.1 definitions of the Char 
and NCName productions should be an implementation-defined feature. 
Section 4.1 does not currently describe this as implementation-defined, 
but it ought to.

------------------------------------------------------------------

Appendix F

Items 20 and 23 in this list appear to be subsets of the 
implementation-defined feature in item 21.

------------------------------------------------------------------

Thanks,

Henry
[Speaking on behalf of reviewers from IBM.]
------------------------------------------------------------------
Henry Zongaro      Xalan development
IBM SWS Toronto Lab   T/L 969-6044;  Phone +1 905 413-6044
mailto:zongaro@ca.ibm.com

This annotated copy of the comment records the current progress in applying these changes
(see lines annotated "MHK"):


Global Editorial

Different elements exhibit different behaviour with respect to import 
precedence.  These differences are frequent sources of confusion. 
Rationale for the particular behaviour of each element should be provided 
in order to aide readers.

MHK: I can't write rationale for something that is irrational. Generally,
I don't think that padding the spec with rationale is a good idea, especially
in respect of retained 1.0 features.

------------------------------------------------------------------

Section 1.1

The fourth paragraph states that "XSLT is used for a wide range of 
XML-to-XML transformation tasks, not exclusively for formatting and 
presentation applications."

Although this is introductory, it might be worth noting that it is also 
used for a range of XML-to-non-XML transformation tasks as well.  For 
example, DOM3 test generation.

MHK: DONE. Deleted "XML-to-XML".

------------------------------------------------------------------

Section 2.3

The fifth bullet in the bulleted list refers to the "default mode".  This 
term should be defined somewhere with a termdef.

MHK: DONE

------------------------------------------------------------------

Section 2.4

The bulleted list of instruction elements should include xsl:param 
(probably with "Instructions that declare variables").  If the list isn't 
intended to be exhaustive, that should be stated or it should be removed 
competely.

MHK: DONE (added xsl:param)

------------------------------------------------------------------

Section 2.5.1

The paragraph that precedes the definition of singleton focus ("Sometimes 
the focus is based on a single node.") doesn't flow very well from the 
paragraph that precedes it.  As it doesn't add anything, it should be 
removed.


MHK: DONE (deleted this para)

------------------------------------------------------------------

Section 2.9

In the paragraph before "Example: Errors in Constant Subexpressions", the 
scope of the "constant expression evaluation" subphase must be 
sufficiently well-defined.  A proper specref in place of "XPath 
specification states" is required, and should consider making "evaluate" 
into a termref.

MHK: I have rewritten this para to include an xspecref to XPath and to use
the identical language that XPath uses.

------------------------------------------------------------------

Section 2.9

The paragraph before "Example: Errors in Constant Subexpressions" 
indicates that "any error occurs during [constant subexpression] 
evaluation. . .  must be held back until the evaluation phase, and 
signaled only if the XPath expression is actually evaluated."

It needs to be made clear that if the implementation can determine that 
the error would always be reported, that it can do so, as described in the 
preceding paragraph.  The wording of the last paragraph might be taken to 
override the permission provided by the preceding paragraph.

MHK: incorporated in the rewrite as mentioned above.

------------------------------------------------------------------

Section 3.3

In the first paragraph, it needs to be made clear that although the 
presence of the extension attribute does not affect the result tree, the 
namespace declaration for that extension will affect the result - in 
particular, the namespace declaration might be present in the result.

MHK: DONE. Added a note advising use of exclude-result-prefixes.

------------------------------------------------------------------

Section 3.6

The second paragraph of the note in this section introduces the concept of 
"entry modules".  Define "entry module" or add a good example.  The 
meaning isn't necessarily immediately clear.

MHK: DONE. Rephrased the note to avoid introducing this concept.

------------------------------------------------------------------

Section 3.8

The second sentence of the third paragraph contains a link to XPath with 
the label "Section".  This appears to be a documentation build error of 
some sort.

MHK: fixed

------------------------------------------------------------------

Section 4.2

It would probably be helpful to point out to users here the potential 
pitfall of using xml:space='preserve' in the presence of xsl:attribute 
elements - it might result in a whitespace text node being created as a 
child of an element before an attribute node is generated.

MHK: DONE (added a cautionary note)

------------------------------------------------------------------

Section 4.3

The second paragraph reads, "The stripping process takes as input a set of 
element names whose child whitespace text nodes are to be preserved."  How 
that set is constructed is only described further on, beneath the syntax 
diagrams for xsl:strip-space and xsl:preserve-space.

That separation makes the quoted sentence seem confusing.  One easily 
makes the mistake that this is actually referring to the pair of 
whitespace-separated lists of NameTests that appear as the values of the 
elements attributes in xsl:strip-space and xsl:preserve-space.

MHK: DONE Added a forwards reference to try and clarify the text.

------------------------------------------------------------------

Section 4.4

The title "Attributes Types and DTD Validation" should be "Attribute Types 
and DTD Validation" or "Attributes' Types and DTD Validation".

MHK: DONE

------------------------------------------------------------------

Section 4.4

In the second paragraph, it would be helpful to provide a little more 
detail about how the equality comparison works.

MHK: DONE. Added an explanation.

------------------------------------------------------------------

Section 5.6.1

The second item in the numbered list, indicates that "Special 
considerations apply to two atomic types for which casting to xs:string is 
not possible. . . ."  However, there is only one such type.

MHK: there is an open issue on these casts. I have added EdNotes to check the text
against the final outcome on this issue. Affects 5.6.2 also.

------------------------------------------------------------------

Section 6.4

The first item in the numbered list states "First, all matching template 
rules that have lower import precedence than the matching template rule or 
rules with the highest import precedence are eliminated from 
consideration."

The wording of this is ambiguous.  It can be read as "First, (all matching 
template rules that have lower import precedence than the matching 
template rule) or (rules with the highest import precedence) are 
eliminated from consideration."

A better wording might be "First, only the matching template rule or rules 
with the highest import precedence are considered. Other matching template 
rules with lower precedence are eliminated from consideration."  The 
second item could then be reworded as "Next, of the remaining matching 
rules, only those with the highest priority are considered. Other matching 
template rules with lower priority are eliminated from consideration."

MHK: DONE. Changed as suggested.

------------------------------------------------------------------

Section 7

In the second paragraph, the use of the term "sorted sequence" is 
potentially confusing, as it might refer to a sequence that hasn't been 
sorted at all.

We would suggest changing " the input sequence is sorted to produce a 
sorted sequence" to "is sorted before being used", and using the term 
"input sequence" instead of "sorted sequence" everywhere else.

MHK: I prefer to leave it as it is. I prefer a functional description
to a procedural one. This means the "input sequence" and the "sorted sequence"
should have different names, and I can't think of any better names.

------------------------------------------------------------------

Section 7

The lead-in to the bulleted list reads "The sequence constructor is 
evaluated with the focus set as follows".

This might read better reworded as "For each item in the sorted sequence, 
the sequence constructor is evaluated with the focus is set as follows:"

MHK: DONE (rephrased).

------------------------------------------------------------------

Section 9.4

The fourth sentence of the first paragraph uses the term "owned by".  This 
term is not defined nor is it used anywhere else.

Suggest changing "evaluating the sequence constructor owned by the 
variable-binding element" to "evaluating the contents of the 
variable-binding elment as a sequence constructor".

MHK: DONE. Changed "owned by" to "contained within".

------------------------------------------------------------------

Section 9.4

In the first sentence of the second paragraph, there is a reference to 
Data Model, but it's not clear what one is being directed to see there. 
The reference should be placed after the words "The base URI of a node".

MHK: DONE. Used an xspecref.

------------------------------------------------------------------

Section 9.4

In the example "Example: Two-Phase Transformation", it probably will not 
be clear to a novice reader that the imported stylesheets in the example 
will define templates only for the particular modes.

MHK: DONE. Explanation added.

------------------------------------------------------------------

Section 9.4

The note suggests it is a good idea to use modes when transforming 
temporary trees.  It should be clarified that that's only necessary if 
different templates actually need to be applied.

MHK: DONE.

------------------------------------------------------------------

Section 10.1.2

In the xsl:number instruction in "Example: Using Tunnel Parameters", 
'format="{$format}"' should be 'format="{$equation-format}"'.

MHK: corrected previously.

------------------------------------------------------------------

Section 10.3

It is easy for a reader to make the mistake that the override attribute 
can be used to prevent a stylesheet function from overriding another 
stylesheet function with the same expanded QName with lower import 
precedence.  It should be made very clear that it can only override 
"built-in" functions.  That could include renaming the attribute to 
something like "override-builtin-functions".  An example illustrating the 
behaviour would also be appropriate.

MHK: DONE. I have added a note to guard against this misreading of the spec.

------------------------------------------------------------------

Section 10.3

The bulleted list describing which stylesheet functions are included in 
the in-scope functions is somewhat confusing.

It would probably be easier to read if reworded to describe the intended 
effect - for example, "A stylesheet function definition suppresses any 
other stylesheet function defintions with the same name and arity that has 
lower import precedence.  It is added to the in-scope functions, unless 
the override attribute has the value "no" and there is a 
processor-provided function of the same name and arity, in which case that 
function will be included in the in-scope functions."

MHK: I have experimented with other ways of expressing this rather complex
set of conditions and have not found a way of doing that is clearer than the
current rules. I propose to leave it as is.

------------------------------------------------------------------

Section 10.3

In the second note, which describes the override attribute, it might not 
be clear that the attribute can override extension functions that might be 
provided by the user, not just functions that are provided by the 
implementation.

MHK: DONE.

------------------------------------------------------------------

Section 11.1.2

The fifth sentence of the third note states, "One consequence of this is 
that these attributes should not be written as attribute value templates: 
although an XSLT processor will understand this notation, the XML parser 
will not."

Making a normative statement with the RFC term "should not" isn't 
appropriate in a note.  Either this needs to be stated normatively or use 
of the RFC "should not" should be avoided.

MHK: DONE. Rewritten using "it is inadvisable..."

------------------------------------------------------------------

Section 11.1.2

The third paragraph of the third note states "None of these attributes 
will be generated in the result tree unless the stylesheet writes them to 
the result tree explicitly, in the same way as any other attribute."

It might not be clear to a user why he or she might have thought these 
attributes would have been generated automatically.  It might be helpful 
to describe the fallacious reasoning that this sentence is trying to 
correct.

MHK: No action. Sorry, but I'm not good at writing fallacious logic.

------------------------------------------------------------------

Section 11.1.2

Error XT0805 is "It is a static error if an attribute on a literal result 
element is in the XSLT namespace, unless it is one of the attributes 
explicitly defined in this specification."

It would be helpful to point out to readers that they might need to use 
namespace aliasing or xsl:element/xsl:attribute if they really need to 
create such attributes in the XSLT namespace.

MHK: DONE (added a note)

------------------------------------------------------------------

Section 11.1.3

It is odd that a feature like exclude-result-prefixes is defined here, 
rather than in its own section.  It might be better as a subsection in the 
Namespace fixup section.

MHK: No change. The reason it is here is to emphasize that ERP applies only
to namespaces generated while processing a literal result element.

------------------------------------------------------------------

Section 11.1.3

A sentence in the third bullet states "It is a static error if there is no 
namespace bound to the prefix on the element bearing the 
[xsl:]exclude-result-prefixes attribute."

The words "prefix on the element" make it sound like this is talking about 
the prefix of the element.  We suggest changing "on the element" to "by 
the element".

MHK: DONE. Rephrased, and added an error code XT0808.

------------------------------------------------------------------

Section 11.1.3

The third bullet makes reference the "The default namespace (as declared 
by xmlns)".  It might be unclear to some readers whether default namespace 
refers to a namespace declared using xmlns="uri" or the default - no 
namespace.  It would be worthwhile defining the term in one place, and 
including termref's to it.

This same comment applies to the second paragraph after the first bulleted 
list in 11.1.4, and in the paragraph in Section 11.2 that defines error 
XT0830.

MHK: I will add a reference to section 6.2 of the Data Model for the definition of "default namespace".

MHK: There also seems to be a missing error condition for the case where #default is used (in 11.1.3) when there
is no default namespace. I have allocated error 0809. (Making this an error is consistent with the treatment
of #default in xsl:namespace-alias).

------------------------------------------------------------------

Section 11.1.3

The last paragraph of the example "Example: Excluding Namespaces from the 
Result Tree" begins "If the stylesheet is changed so that the literal 
result element has an attribute b:bar="3", then the element in the result 
tree will typically have a namespace declaration xmlns:b="b.uri", although 
the processor is free to choose a different namespace prefix if it 
wishes."

This should be reworded to indicate that some namespace declaration for 
the namespace must be available, rather than appealing to the typical 
behaviour.

MHK: No change, This is only an example, so I prefer to make it a concrete example
of how a real processor might behave, not a generalized description of all the possibile behaviors.

------------------------------------------------------------------

Section 11.1.3

The material that appears in the last paragraph of the example "Example: 
Excluding Namespaces from the Result Tree" would be better placed in 
Section 5.6.3.

MHK: No change. The material belongs with the example that precedes it.

------------------------------------------------------------------

Section 11.1.4

The second note in this section states, "The processor still has a free 
choice of prefixes when generating element and attribute names in the 
result tree, but it will normally use the result-prefix since that prefix 
will already be declared in the result tree."

As this is implementation dependent, the note shouldn't refer to the 
"normal" behaviour.  If we want to make a normative statement, that can't 
be handled editorially.

MHK: Actually, the choice of prefix is quite constrained, under the namespace fixup
rules. I have deleted the quoted sentence.

------------------------------------------------------------------

Section 11.1.4

In the example box, the paragraph before the second stylesheet states in 
part, "however, the rules guarantee that there will be a namespace node 
that binds the prefix xsl to the URI http://www.w3.org/1999/XSL/Transform, 
which makes it safe to use the QName xsl:version in the content of the 
generated stylesheet."

It might not be clear to the reader which rules guarantee this.  That 
should be explicitly stated.

MHK: It's the combination of all the rules. I don't think it would help to
restate them: the reader is just going to have to work through all the rules to
confirm that they do indeed give the answer as shown. We're not going to make
namespace-alias easy to understand, however hard we try.

------------------------------------------------------------------

Section 11.1.4

It might be worthwhile to add a note that describes the merits of using 
xsl:attribute and xsl:element over using namespace aliasing.  For example, 
"xsl:element and xsl:attribute (see following sections) can also be 
practical solutions for the tasks commonly addressed via namespace 
aliasing. They have the advantages of being more direct and of permitting 
more explicit "hinting" about the desired prefix, at the expense of being 
more verbose. Users may wish to consider both approaches and select the 
one which best suits their needs."

MHK: I have added a note along these lines, suggesting the alternative 
approach but without discussing its relative merits.

------------------------------------------------------------------

Section 11.2

In the description of the recovery action for Error XT0820, it might be 
worthwhile to add that the xsl:element is replaced by its children, in 
case the effect of the recovery isn't clear to all readers.

MHK: I have raised a separate comment (review of dynamic errors) which 
would remove this recovery action.

------------------------------------------------------------------

Section 11.2

The recovery action for Error XT0820 is potentially surprising.  Some 
rationale for the recovery action might be appropriate.

MHK: I have raised a separate comment (review of dynamic errors) which 
would remove this recovery action.

------------------------------------------------------------------

Section 11.2

The recovery action for XT0830 is "to ignore the prefix part of the 
lexical QName, with the effect that the new element will be in the default 
namespace."  It is not clear whether the element is in the default 
namespace of the result or the default namespace of the stylesheet.

MHK: changed this to read: "...with the effect that the 
name of the new element will be in the default namespace
of the xsl:element instruction if the instruction has a default namespace, and will be
in no namespace if it does not."

------------------------------------------------------------------

Section 11.3

Error XT0840 states "It is a static error if the select attribute of the 
xsl:attribute element is present unless the element has empty content." 
Section 5.6 deals with stripping of whitespace nodes in this situation, 
but it might make things more clear to say "unless the element has empty 
content after whitespace nodes have been stripped from the stylesheet."

MHK: I think there are many places where we would need to make such changes. The
point of pulling the whitespace stripping into one place is that we only need
to say it once. No change.

------------------------------------------------------------------

Section 11.4.2

In the second paragraph, the phrase "either a single node, the newly 
constructed text node, or an empty sequence" might be taken to present 
three choices rather than two.  It should be rephrased as "either the 
newly constructed text node or an empty sequence."

MHK: DONE.

------------------------------------------------------------------

Sections 11.4.2 and 11.4.3

These sections should state that the text created by xsl:text or 
xsl:value-of instructions might be merged with other adjacent text into a 
single text node.  This is only stated explicitly in the case of literal 
text nodes in 11.4.1.

MHK: DONE. The note has been moved up a level, to 11.4, and expanded.

------------------------------------------------------------------

Section 11.5

The note begins "This means that xsl:processing-instruction cannot be used 
to output an XML declaration."  It is not clear what the antecedent of 
"this" is.  Is it the rule in XT0890 or the fact that xsl:attribute cannot 
be used to construct the pseudo-attributes of a processing instruction?

MHK: DONE (clarified)

------------------------------------------------------------------

Section 11.6

The sections on xsl:element and xsl:attribute state "The effective value 
[of the namespace attribute] should be a URI reference.  It is not an 
error if the string is not a syntactically legal URI reference."  A 
similar statement is required for xsl:namespace.

MHK: DONE

------------------------------------------------------------------

Section 11.6

The second paragraph of the first note in this section states that adding 
a namespace node to the result tree "does, however, constrain the choice 
of prefixes when namespace fixup is performed."

The word "does" should be changed to "might" - adding such a namespace 
node could also increase the number of choices available or have no effect 
on the choice.

MHK: DONE

------------------------------------------------------------------

Section 11.8.1

The second note states "but if namespaces are used in the content of the 
attribute. . . then it is the responsibility of the stylesheet author to 
ensure that suitable namespace declarations are added to the result tree."

This should really begin "but if namespace prefixes are used. . . ."  A 
namespace URI could be used inside of an attribute without requiring any 
namespace declaration.

MHK: DONE

------------------------------------------------------------------

Section 13.1.2

The second paragraph uses the term "converted" twice.  This should be 
"cast" to avoid any confusion about the meaning of the term.

MHK: No. The following sentence explains that conversion is done using the
string() or number() function, it is not done using the casting rules.

------------------------------------------------------------------

Section 13.1.3

The paragraph after the second note indicates that the lang and case-order 
attributes "identify a suitable collation".  It should be noted that for 
any particular combination of lang and case-order, there may be more than 
one suitable collation.

MHK: I've changed "identify" to "locate". (I hate the word "locate",
because it really means "to place in a location", not "to find". But I think
it's OK here).

------------------------------------------------------------------

Section 14.3

The last sentence in the second paragraph states that "A group is never 
empty."  The fifth paragraph begins with the sentence "If the population 
is empty, the number of groups will be zero."  These two related sentences 
should probably appear closer to one another.

MHK: DONE

------------------------------------------------------------------

Section 14.3

In the definition following XT1090, there is no term that is in bold type 
that is being defined.  Is this defining "grouping key"?

MHK: DONE (improved the definition)
------------------------------------------------------------------

Section 14.3

The definition of "processing order" ends prematurely.  To complete the 
definition, the two sentences that follow should probably be included in 
the definition.  Otherwise, the definition should be reworded in order to 
stand alone.

MHK: DONE (improved the definition)

------------------------------------------------------------------

Section 14.3

The title of the example box "Example: Sorting Groups in order of their 
Grouping Key" isn't accurate - it includes two examples, only one of which 
uses a grouping key.

MHK: DONE (changed the title)

------------------------------------------------------------------

Section 15.1

The paragraph following XT1150 begins "The xsl:analyze-string instruction 
starts at the beginning of the input string and attempts to find the first 
substring that matches the regular expression."

It doesn't seem appropriate to talk about this particular complexity of 
regular expression matching, out of all the other complexities discussed 
in the F&O. A reference to F&O would probably be more appropriate.

MHK: This would be fair comment if there were a common description that replace(),
tokenize(), and analyze-string could all refer to. But there isn't. No change.

------------------------------------------------------------------

Section 15.2

In the definition of "current captured substrings", "parenthized" should 
be "parenthesized".

MHK: DONE

------------------------------------------------------------------

Section 15.2

The behaviour of the regex-group function is not sufficiently specified 
when it is used within xsl:non-matching-substring and outside of 
xsl:analyze-string - in particular, how is an argument value of zero 
handled in those situations?  It's not clear whether the matching string 
is considered to be considered to be a one of the current captured 
substrings, and so, part of the sequence, which would imply that 
regex-group(0) should return the zero-length string in those situations, 
or whether it is still "the same as the value of . (dot)" in those 
situations.

MHK: Good point (it's really a technical point rather than editorial). 
I have clarified it.  

------------------------------------------------------------------

Section 16.1

The last rule in this section begins "The effect of these rules. . . ." 
These rules have more than one effect; this should be "One effect of these 
rules. . . ."

MHK: DONE

------------------------------------------------------------------

Section 16.2

The second paragraph indicates that "The URI must contain no fragment 
identifier. . . ."  Presumably this is because the text has no known 
structure.  It would be helpful to state the rationale behind the 
restriction.

MHK: we could support fragment identifiers for specific media types
such as HTML, I think the rationale is to reduce the burden on the
implementation. On the whole, I prefer to avoid including rationale
for this kind of thing: the spec is not required to justify itself.

------------------------------------------------------------------

Section 16.2

The paragraph following the first note, states "This encoding is used to 
translate the contents of the file into a string."  More accurately, it 
specifies a default unless file-specific information is available as 
described further on.

MHK: I have deleted the offending sentence.

------------------------------------------------------------------

Section 16.3.2

The paragraph following the bulleted list describes the interpretation of 
the current function when it appears in match or use in xsl:key.  This 
really belongs in 16.3.1 - though the wording might be complicated by the 
fact that it can't refer to the node N that is being considered.

MHK: I have deleted the paragraph. It is already covered by the rules for the
current() function in 16.6.1.

------------------------------------------------------------------

Section 16.5.2

The seventh paragraph reads as follows:

<<
The choice of the names and abbreviations used in any given language is 
implementation-defined. For example, one implementation might abbreviate 
July as Jul while another uses Jly. In German, one implementation might 
represent Saturday as Samstag while another uses Sonnabend. 
Implementations may provide mechanisms allowing users to control such 
choices.
>>

It should be explicitly stated that mechanisms that allow users to control 
such choices must not be in the form of additional, implementation-defined 
presentation modifiers.

MHK: I don't think this is true. The set of presentation modifiers is defined
by reference to format tokens allowed by xsl:number, and xsl:number explicitly
allows additional implementation-defined format tokens.

------------------------------------------------------------------

Section 16.6.5

The sentences before and after the note in this section are related, and 
should probably be placed in a single paragraph, rather than being 
separated by a note.

MHK: DONE

------------------------------------------------------------------

Section 18.1

The first paragraph of this section needs to deal with the fact that the 
stylesheet function with highest import precedence might have specified 
the override attribute with a value of "no".  We understand that the 
reference would be to the extension function in this case.

MHK: Yes. It also needs to handle the case where it is a constructor
function for a user-defined (or built-in) atomic type, or where the
prefix identifies the fn: namespace. Reworded.

------------------------------------------------------------------

Section 18.2.2

The first paragraph states, "The element-available function can be used 
with the xsl:choose and xsl:if instructions to explicitly control how a 
stylesheet behaves if a particular extension instruction is not 
available."

The element-available function applies to instructions in the XSLT 
namespace as well as to extension instructions.  The quoted sentence needs 
to be reworded.

Given that the function applies to more than just extension instructions, 
perhaps it should be moved to another section.

MHK: I will leave it where it is, but emphasize that it also tests
availability of XSLT instructions.

------------------------------------------------------------------

Section 19

In the second paragraph, suggest changing "may be created" to "can be 
created", to avoid confusion with the RFC term.

MHK: DONE

------------------------------------------------------------------

Section 19

The fourth paragraph begins "A result tree has a URI."  We would suggest 
this be changed to "A result tree is assigned a URI when it is created" or 
perhaps "A result tree is assigned an absolute URI when it is created."

MHK: DONE

------------------------------------------------------------------

Section 19

The first note begins "The URI of the result tree is not the same thing as 
the URI of its serialized representation. . . ."  The words "is not the 
same thing" are too strong; perhaps, it should be "is not necessarily the 
same thing"

MHK: DONE

------------------------------------------------------------------

Section 19

The last sentence of the first note begins "As long as it satisfies 
requests. . . ."  It is not clear what the antecedent of "it" is in this 
case.  Perhaps this should be "As long as the API satisfies requests. . . 
."

MHK: Changed to "the processor"

------------------------------------------------------------------

Section 19

All this description of how the URI that is associated with the result 
tree might be utilized by an API seems like it belongs with the 
description of the href attribute in section 19.1, as it specifies the 
URI.

MHK. Yes. text moved.

------------------------------------------------------------------

Section 19

In the last note, the phrase "is unrelated" is too strong.  We would 
suggest "may differ from"

MHK: DONE
------------------------------------------------------------------

Section 19.1

The fourth paragraph following XT1460 states that "An implementation that 
does not support the serialization of result trees. . . must provide the 
application with some means of access to the (un-serialized) result tree, 
optionally using its URI to identify it."  However, the fourth paragraph 
of Section 19 states that "If the implementation provides an API to access 
result trees, then it must allow a final result tree to be identified by 
means of this URI."

The two statements differ as to whether an API must allow result trees to 
be identified by URI.

MHK: deleted "optionally".

------------------------------------------------------------------

Section 19.2

A brief summary of the distinction between the validity and type 
attributes -- validity tests for any valid type, while type insists on 
validating against a specified type, if I'm reading this correctly -- 
would tremendously improve readability of this section, by setting context 
and giving the reader some guidance as to the differences in syntax and 
semantics.

MHK: DONE

------------------------------------------------------------------

Section 19.2.1

The first and second subbullets of the third bullet in the first bulleted 
list indicate that in certains circumstances the "transformation fails."

It would be helpful to provide a link to the error that is reported in 
each case, because the definitions of the definitions of those errors are 
so far-removed.

MHK: DONE

------------------------------------------------------------------

Section 19.2.1

The third subbullet of the the third bullet in the first bulleted list 
states that "The schema components used to validate an element or 
attribute may be located in any way permitted by [XML Schema]."  The word 
"permitted" is too strong; the section of XML Schema that is cited just 
describes a number of possibilities, without any restrictions.  Perhaps 
"described" would be a better word.

MHK: done.

Where the remainder of the bullet indicates that the processor might have 
implicit knowledge of a namespace or may use a schemaLocation to locate 
schema components, it should be made clear that those are just two 
possibilities - not an exhaustive list.

MHK: done

------------------------------------------------------------------

Section 19.2.1

The third bullet of the second bulleted list states, "If the element or 
attribute is not considered valid, the transformation fails."  For 
clarity, the word "valid" should be changed to "a valid instance of the 
specified type".

MHK: after "considered valid" I have added "as defined above".

------------------------------------------------------------------

Section 19.2.1

The first part of this section is specific to [xsl:]validation; the second 
part is specific to [xsl:]type.  It is not clear whether the paragraphs 
and bulleted lists following the last note in this section only apply if 
the [xsl:]type attribute is specified.

MHK: I have added some level-4 headings to make things clearer.

------------------------------------------------------------------

Section 20

The paragraph following XT1560 states that "The values of attributes are 
defaulted after the xsl:output elements have been merged. . . ."  However, 
if no method attribute is specified, not all of the default attribute 
values are necessarily known after merging.

MHK: I have rewritten the paragraph.

------------------------------------------------------------------

Section 20

The third bullet from the end of the list states, "The 
undeclare-namespaces attribute is relevant only when producing output with 
method="xml" and version="1.1"."  This should probably be rephrased to 
allow for future versions of XML.

MHK: done

------------------------------------------------------------------

Section 21

The note in this section refers to the static typing feature.  Some 
normative statement about this feature should be provided - perhaps in 
section 2.8

MHK: the note says that there is no static typing feature. There is no need
to say that normatively.

------------------------------------------------------------------

Section 21.1

The second note indicates that a processor might ignore non-trivial type 
annotations from PSVI in order to construct a data model that conforms to 
the requirements of a basic XSLT processor.  It should also be noted that 
the data model cannot be constructed from Infoset as described in the Data 
Model document, as that can result in attributes with types that aren't 
permitted for a basic XSLT processor - such types would similarly have to 
suppressed in order to construct a data model that conforms to the 
requirements of a basic XSLT processor.

MHK: I've extended the note.

------------------------------------------------------------------

Appendix F

Whether a processor supports the XML 1.0 or 1.1 definitions of the Char 
and NCName productions should be an implementation-defined feature. 
Section 4.1 does not currently describe this as implementation-defined, 
but it ought to.

MHK: done.

------------------------------------------------------------------

Appendix F

Items 20 and 23 in this list appear to be subsets of the 
implementation-defined feature in item 21.

MHK: I have consolidated the list.

------------------------------------------------------------------


      

Status changed to "announced"

Section K

The way this section is laid out is confusing.  For instance, K.1.2 
indicates that it describes incompatibilities that occur when BC is not 
enabled, but many of the items in the list in that subsection apply when 
BC is enabled as well.

Perhaps subsections organized similarly to XPath's compatibility appendix 
(BC is true, BC is false, in presence of schema) could be used instead.

Thanks,

Henry
[Speaking on behalf of reviewers from IBM.]
------------------------------------------------------------------
Henry Zongaro      Xalan development
IBM SWS Toronto Lab   T/L 969-6044;  Phone +1 905 413-6044
mailto:zongaro@ca.ibm.com

            
 
MK: Editorial and correct criticizm

***Action:  MK will fix the wording

[** change already made as an editorial fix in response to an off-list comment - MHK]

            
         

ection 21

It does not appear to be anywhere stated as part of conformance that a 
processor must support all F&O functions.

Thanks,

Henry
[Speaking on behalf of reviewers from IBM.]
------------------------------------------------------------------
Henry Zongaro      Xalan development
IBM SWS Toronto Lab   T/L 969-6044;  Phone +1 905 413-6044
mailto:zongaro@ca.ibm.com

Discussion: http://lists.w3.org/Archives/Public/public-qt-comments/2004Feb/1105.html

I believe this requirement is implicit in the definition of the in-scope
functions in the static context for XPath evaluation defined in section
5.3.1. However, if you want a stronger statement, we can discuss this in
the WG. I will leave this issue open for now.

Michael Kay

            
 
Conformance rule that must report all F&O  functions.

MK: Need more explicit text in conformance  section.

SB: wants to bring this up at the next F2F.

***Action:  Put on F2F agenda.
            
         

qt-2004Feb1087-01: [XSLT2.0] IBM-XSLT-125: Need to state that an XSLT processor must support all
 F&O functions
we need a change in 5.3.1 of xslt 2.0 to say that the inscope functions for an XPath expression 
also include constructor functions for the atomic types in the inscope schema definitions.
 
comment ACCEPTED. Yes, say all of F and O to be supported, and revise the term 'core functions'.

** Changes made - draft U - MHK
      

Section 20

The paragraph before the final bulleted list in this section states, "The 
default output method is used if there are no xsl:output elements or if 
none of the xsl:output elements specifies a value for the method 
attribute."

It might not be clear to the reader that the default that is selected only 
applies to the particular result tree that is being serialized.  In other 
words, if two xsl:result-document instructions use the same output 
definition, and that definition has no method specified, each result 
document could use a different default method.

Thanks,

Henry
[Speaking on behalf of reviewers from IBM.]
------------------------------------------------------------------
Henry Zongaro      Xalan development
IBM SWS Toronto Lab   T/L 969-6044;  Phone +1 905 413-6044
mailto:zongaro@ca.ibm.com

I propose to fix it by changing the sentence:

"The default for the method attribute is chosen as follows:"

to read:

"The default for the method attribute depends on the contents of the tree being serialized, and is chosen as follows:"

(change applied - MHK)

Status changed to "announced"

Section 20

The paragraph before the final bulleted list in this section states, "The 
default output method is used if there are no xsl:output elements or if 
none of the xsl:output elements specifies a value for the method 
attribute."

This needs to be rephrased to refer to the output definition - only the 
output definition that is being used to serialize the result tree is 
relevant here.  The fact that xsl:output elements associated with other 
output definitions specified values for the method attribute is 
irrelevant.

Thanks,


Henry
[Speaking on behalf of reviewers from IBM.]
------------------------------------------------------------------
Henry Zongaro      Xalan development
IBM SWS Toronto Lab   T/L 969-6044;  Phone +1 905 413-6044
mailto:zongaro@ca.ibm.com

Thanks for pointing out the need to clarify this.

I intend:

(a) to add a sentence explaining that there is always an unnamed output definition, which
 in the absence of an <xsl:output> element with no name attribute is equivalent to 
 specifying an <xsl:output> declaration having no attributes;

(b) to amend the sentence you refer to, to say "The default output method is used
 if the selected output definition does not include a [method] attribute".
 
 (Change applied - MHK)

Section 19.1

Error XT1490 indicates that it is a non-recoverable dynamic error for two 
or more result trees to have the same URI.  However, there could be other 
illegal combinations that should be considered dynamic errors, though 
there might be no way for an implementation to report the error or to 
recover in any useful fashion. For instance, if distinct URI's specified 
on different xsl:result-document instructions refer to the same physical 
resource.

Similarly, if xsl:result-document specifies a particular URI, and a 
reference to fn:doc actually identifies the same resource created by the 
xsl:result-document instruction, a dynamic error should result, though an 
implementation might not be able to detect it. 

<xsl:result-document href="file:///example">
  <xsl:copy-of select="fn:doc('file:///example')"/>
</xsl:result-document>

Thanks,

Henry
[Speaking on behalf of reviewers from IBM.]
------------------------------------------------------------------
Henry Zongaro      Xalan development
IBM SWS Toronto Lab   T/L 969-6044;  Phone +1 905 413-6044
mailto:zongaro@ca.ibm.com

            
 
non-recoverable dynamic error for two
or more result trees to have the same URI etc.

HZ: class of dynamic error to describe this type

MK: introduced a class of system errors outside  boundary

SB: should specifically rule out this error even  though processor may not
be able to detect this

***Action:  MK will define new error condition.

*** Done, error 1495 added.
            
         

Section 18.1.2

Error XT1420 describes circumstances in which a reference to an extension 
function results in a non-recoverable dynamic error.  The implementation 
should also be given the option of having an extension function produce 
recoverable dynamic errors.

Thanks,

Henry
[Speaking on behalf of reviewers from IBM.]
------------------------------------------------------------------
Henry Zongaro      Xalan development
IBM SWS Toronto Lab   T/L 969-6044;  Phone +1 905 413-6044
mailto:zongaro@ca.ibm.com

            
 
***Action:  MK will propose extensions for  wording on error condition

[MHK: proposal made 2004-05-17 on xsl-wg list]
            
         

            
 
[XSLT2.0] IBM-XSLT-121: Dynamic errors for references to extension functions

Status:
MHK took an action to proposed revised wording.
The action was completed: see
http://lists.w3.org/Archives/Member/w3c-xsl-wg/2004May/0036.html

ACCEPTED. with action on Mike to generalize error handling to
extension elements.

** done, in draft U - MHK

            
         

Section 16.5.1

The second bullet in the bulleted list in this sections states that 
"Components that can be output by name include (but are not limited to) 
months, days of the week, timezones, and eras."  It is not clear from that 
statement whether an implementation MUST support output of those 
components by name, or it is merely mentioning some components for which 
output by name might be supported.

We believe that it was intended to just mention instances in which output 
by name might make sense, but in no way mandate which must be supported.

Thanks,

Henry
[Speaking on behalf of reviewers from IBM.]
------------------------------------------------------------------
Henry Zongaro      Xalan development
IBM SWS Toronto Lab   T/L 969-6044;  Phone +1 905 413-6044
mailto:zongaro@ca.ibm.com

            
 
***Action:  MK will write up wording
[Done. MHK]
            
         

Section 16.2

In the paragraph following the first note, the phrase "The only values 
which every implementation is obliged to recognize" appears.  The words 
"is obliged to" should be replaced with "MUST".

Thanks,

Henry
[Speaking on behalf of reviewers from IBM.]
------------------------------------------------------------------
Henry Zongaro      Xalan development
IBM SWS Toronto Lab   T/L 969-6044;  Phone +1 905 413-6044
mailto:zongaro@ca.ibm.com

Proposal accepted by editor.

(2 occurrences of "obliged" changed to "required", with RFC markup - MHK)

Section 16.1

The last note in this section describes the trick of using document('') to 
refer to the document node of the stylesheet module.  The note points out 
that this will not necessarily refer to the stylesheet if either XML 
entities or xml:base is used.  It should also be noted that if the 
stylesheet module has no base URI, this method will not work.

Thanks,

Henry
[Speaking on behalf of reviewers from IBM.]
------------------------------------------------------------------
Henry Zongaro      Xalan development
IBM SWS Toronto Lab   T/L 969-6044;  Phone +1 905 413-6044
mailto:zongaro@ca.ibm.com

            
 
MK: does the data model allow an unknown base  uri?

HZ: DMbaseURI accessor returns 0 or 1 URI  references.

MK: RFC2396 empty URI issue

***Action:  MK will write up wording

[MHK: the discussion concluded that base URI was an optional property and that if the property was
absent from the stylesheet document, the document("") trick would not work.]

[Done - MHK]
            
         

ection 15.1

The first paragraph beneath the syntax for the xsl:non-matching-string 
element states, in part, "The xsl:analyze-string instruction takes as 
input a string (the result of evaluating the expression in the select 
attribute)...."  This needs to specify how the value of the expression is 
converted to a string.

Thanks,

Henry
[Speaking on behalf of reviewers from IBM.]
------------------------------------------------------------------
Henry Zongaro      Xalan development
IBM SWS Toronto Lab   T/L 969-6044;  Phone +1 905 413-6044
mailto:zongaro@ca.ibm.com

I propose to add the rule:

If the result of evaluating the select expression is not a string, it is converted
 to a string by applying the *function conversion rules* [link to definition in section 5.3].

(An alternative would be to appeal to the fn:string() function; but it seems
 more natural to me to use the function conversion rules, which mean that you
  will get stronger type checking)


(Change applied - MHK)

Status changed to "announced"

Section 12.3

In the last paragraph before "Example: Ordinal Numbering in Italian", the 
description of ordinal numbering is underspecified.  This should indicate 
that the supported combinations are implementation-defined.

Thanks,

Henry
[Speaking on behalf of reviewers from IBM.]
------------------------------------------------------------------
Henry Zongaro      Xalan development
IBM SWS Toronto Lab   T/L 969-6044;  Phone +1 905 413-6044
mailto:zongaro@ca.ibm.com

DECISION: qt-2004Feb1078-01 ACCEPTED.

*** MK:  text updated.
      

Section 11.2

The last paragraph of this section states, in part, "Implementations MAY 
make use of the prefix of the lexical QName. . . ."  It would be 
preferable to strongly encourage this with the word SHOULD, rather than 
MAY.

Thanks,

Henry
[Speaking on behalf of reviewers from IBM.]
------------------------------------------------------------------
Henry Zongaro      Xalan development
IBM SWS Toronto Lab   T/L 969-6044;  Phone +1 905 413-6044
mailto:zongaro@ca.ibm.com

Some discussion...
DECISION: REJECTED.
      

Section 11.1.4

The second bulleted list reads as follows:

<<
When a literal result element is processed, its namespace nodes are 
handled as follows:

o A namespace node whose string value is a literal namespace URI is
  not copied to the result tree.

o A namespace node whose string value is a target namespace URI is
  copied to the result tree, whether or not the URI identifies an
  excluded namespace.
>>

This seems to be a change from XSLT 1.0.  In XSLT 1.0, a namespace node 
whose string value was declared to be an alias for another resulted in a 
namespace node in the result tree whose string value was the correspond 
URI.  The text quoted above indicates that no such translation will occur 
in XSLT 2.0.  If this change in semantics was not intended, the quoted 
text could be replaced with the following:

<<
A namespace node whose string value is a literal namespace URI will not be 
copied to the result tree; instead a namespace node whose string value is 
the corresponding target namespace URI will be produced
>>

Thanks,

Henry
[Speaking on behalf of reviewers from IBM.]
------------------------------------------------------------------
Henry Zongaro      Xalan development
IBM SWS Toronto Lab   T/L 969-6044;  Phone +1 905 413-6044
mailto:zongaro@ca.ibm.com

Discussion: see http://lists.w3.org/Archives/Public/public-qt-comments/2004Feb/1100.html

(paraphrased from minutes by MHK)
MK: The new text intentionally strengthens the spec to make it explicit which namespace 
prefix will be used in the output. There were use cases considered in Bangkok, e.g. generation
of a stylesheet that has QNames in content.
DECISION: REJECTED.
      

Section 11.1.2

The last sentence of the first note states, "In practice, it makes no 
difference whether the namespace nodes come before or after the 
attributes."  The meaning of this statement is not clear. It seems to 
imply that namespace nodes for an element could follow attribute nodes for 
that same element in document order, and that that would make no 
difference - which is false per the Data Model.

Thanks,

Henry
[Speaking on behalf of reviewers from IBM.]
------------------------------------------------------------------
Henry Zongaro      Xalan development
IBM SWS Toronto Lab   T/L 969-6044;  Phone +1 905 413-6044
mailto:zongaro@ca.ibm.com

I propose to respond by changing the sentence (in the Note) from:

In practice, it makes no difference whether the namespace nodes come before or after the attributes.

to:

Although the above rules place namespace nodes before attributes, 
this is not strictly necessary, because the rules in 5.6.1 Constructing 
Complex Content allow the namespaces and attributes to appear in any 
order so long as both come before other kinds of node. The order 
of namespace nodes and attribute nodes in the sequence has no effect 
on the relative position of the nodes in document order once they 
are added to a tree.

** change applied - MHK

Status changed to "announced"

Section 10.3

In the paragraph beneath error XT0770, the error for a function reference 
that is not in the in-scope functions is described as a "dynamic error". 
It should be a "non-recoverable dynamic error".

Thanks,

Henry
[Speaking on behalf of reviewers from IBM.]
------------------------------------------------------------------
Henry Zongaro      Xalan development
IBM SWS Toronto Lab   T/L 969-6044;  Phone +1 905 413-6044
mailto:zongaro@ca.ibm.com

Change made as requested. Also added a cross-reference to error XT1410.

(Change applied - MHK).

Status changed to "announced"

Section 10.1.1

The first note in this section states, in part, "In this situation, the 
computed value of the parameter will be validated and/or converted twice."

Was it really the intent that the consequence of using the as attribute 
would be anything other than to invoke the function conversion rules? What 
is implied by the terms "validated and/or converted", which don't seem to 
be well-defined?  Converted might refer to the function conversion rules, 
but what of validated?

Thanks,

Henry
[Speaking on behalf of reviewers from IBM.]
------------------------------------------------------------------
Henry Zongaro      Xalan development
IBM SWS Toronto Lab   T/L 969-6044;  Phone +1 905 413-6044
mailto:zongaro@ca.ibm.com

I agree that the phrase "validated and/or converted" is fuzzy.

I propose to replace the sentence:

In this situation, the computed value of the parameter will be validated
and/or converted twice, first according to the rules of the as attribute
on the xsl:with-param element, and then according to the rules of the as
attribute on the xsl:param  element.

by

In this situation, the supplied value of the parameter will first be
processed according to the rules of the as attribute on the
xsl:with-param element, and the resulting value will then be further
processed according to the rules of the as attribute on the xsl:param
element. 

For example, suppose the supplied value is a node with type annotation
xdt:untypedAtomic, and the xsl:with-param element specifies
as="xs:integer", while the xsl:param element specifies as="xs:double".
Then the node will first be atomized and the resulting untyped atomic
value will be cast to xs:integer. If this succeeds, the xs:integer will
then be promoted to an xs:double.

I would be grateful if you could confirm that this clarifies the
specification adequately.

Regards

Michael Kay
(as XSL WG editor)


** Minutes of 1 July 2004 accepted this resolution but actioned 
Scott Boag to confirm that the revised wording is OK.

Section 4.5

Second paragraph states that the disable-output-escaping atribute is 
supported on xsl:attribute, but it's not.

Thanks,

Henry
[Speaking on behalf of reviewers from IBM.]
------------------------------------------------------------------
Henry Zongaro      Xalan development
IBM SWS Toronto Lab   T/L 969-6044;  Phone +1 905 413-6044
mailto:zongaro@ca.ibm.com

Comment accepted.

Change applied - MHK

Status changed to "announced"

Section 4.4

The second paragraph states, "In general, creating type annotations based 
on DTD attribute types is likely to create some backwards compatibility 
problems."  In reality, the backwards compatibility issues are caused by 
the fact that XSLT accesses typed data, rather than being caused by DTD's. 
 This should be rephrased to correctly characterize the source of the 
problem.

Thanks,

Henry
[Speaking on behalf of reviewers from IBM.]
------------------------------------------------------------------
Henry Zongaro      Xalan development
IBM SWS Toronto Lab   T/L 969-6044;  Phone +1 905 413-6044
mailto:zongaro@ca.ibm.com

If you can suggest a better wording, please do. I don't quite follow
what you're saying about "the source of the problem". 

I have to say I'm not comfortable with section 4.4. I think the section
is basically passing the buck to the implementor. I think we need to
look at this again and see if we can do better. It's tricky because of
our decision that we don't define how trees get constructed, but I think
we should have a defined mapping of DTD-validated documents to the data
model that we at least recommend to implementors, rather than "merely
pointing out some of the consequences of the decision".

Michael Kay

      
Summary: general consensus that the situation was a mess, and there were no clear solutions.
One proposal was to ignore all DTD types except ID (and perhaps IDREF)
ACTION: MK: will try to improve the wording a bit to address the complaint 
without actually changing the meaning...
DECISION: ACCEPTED (with MK's action).
      

         We have a number of long-standing problems concerned with DTD-based types.

One of these is XSLT issue 

qt-2004Feb1071-01
    [XSLT2.0] IBM-XSLT-109: Typed data and backwards compatibility

In XSLT we have the problem that in a non-schema-aware product, we say that
no type annotations are allowed on nodes, other than the trivial type
annotations xdt:untyped and xdt:untypedAtomic. But for backwards
compatibility, we need to support the id() function, which only works if
nodes have a type annotation of xs:ID.

Moreover, we need to support well-formed documents that are not valid. In a
DTD world, we can be notified that an attribute id="xyz:123:abc" is an ID
value even though it is not a valid instance of xs:ID. (This is because
non-validating parsers can and do notify the attribute type defined in the
DTD).

We also have a backwards compatibility problem with NMTOKENS. Given an
attribute a="red green" of type NMTOKENS, the expression [contains(@a,
'green')] in XPath 1.0 returns true. In XPath 2.0 with BCM it return
false(!), and without BCM it is a type error. 

I believe the right solution to these problems is as follows:

(a) change the data model so element and attribute nodes have a new boolean
property, the isID property. Construction from a PSVI sets this property if
and only if the type is xs:ID or derived from restriction from xs:ID.
Construction from an InfoSet sets this property if and only if the node is
an attribute and the [attribute type] is "ID".

(b) similarly, change the data model so element and attribute nodes have a
new boolean property, the isIDREFS property. Construction from a PSVI sets
this property if and only if the type is xs:IDREF or xs:IDREFS or a type
derived therefrom by restriction. Construction from an InfoSet sets this
property if and only if the node is an attribute and the [attribute type] is
"IDREF" or "IDREFS".

(c) change the rules for construction from an InfoSet so that [attribute
type] is ignored, except as specified in (a) and (b) above. (This doesn't
preclude implementation options to use the attribute type as currently
specified).

(d) change the rules for the id() function so that it relies on the isID
property of the element and attribute nodes, not on their type annotation.

(e) change the rules for the idref() function so that it relies on the
isIDREFS property of the element and attribute nodes, not on their type
annotation.

Michael Kay
         

J10. DTD-based types, Michael K
Some discussion is recorded in the minutes...

DECISION to adopt Mike Kay's proposed solution, with editorial instruction 
to implement in Data Model and F+O.

ACTION A-200-04 on Mike Kay to ask Norm and Ashok by email if they can 
implement the changes from Mike's proposal in 
http://lists.w3.org/Archives/Member/w3c-xsl-query/2004Jul/0012.html, and on 
Norm and Ashok to implement that proposal.
         

[With apologies that these comments are coming in after the end of the 
Last Call comment period.]

Section 4.3

The second note in this section describes a potentional optimization.  In 
fact, the optimization described can only apply if the various 
transformations all specify the same sets of NameTests in their 
xsl:strip-space and xsl:preserve-space declarations.

We would suggest that this note be removed, as it raises more questions 
than it answers.

Thanks,

Henry
[Speaking on behalf of reviewers from IBM.]
------------------------------------------------------------------
Henry Zongaro      Xalan development
IBM SWS Toronto Lab   T/L 969-6044;  Phone +1 905 413-6044
mailto:zongaro@ca.ibm.com

I personally agree with you and recommend that the WG accepts your
proposal to remove this Note, however, I would prefer to have the WG
confirm this decision rather than treating the decision as purely
editorial. I will leave the issue open for now.

Michael Kay

NW: Loose it!
DECISION: ACCEPTED.

** MHK: text updated.
      

Section 4.2

Bullets 4 and 5 in this section specify circumstances in which the value 
of the xml:space attribute in a stylesheet should be ignored, and 
whitespace stripped from the stylesheet.  This is done to prevent the 
presence of whitespace nodes resulting in violations of the required 
content of an element in the XSLT namespace.  Consider the following 
stylesheet fragment:

<xsl:template match="/">
  <out xml:space="preserve">
    <xsl:attribute name="attr">value</xsl:attribute>
  </out>
</xsl:template>

The preserved whitespace node in this example always results in a 
recoverable syntax error (XT0410).  The Working Group should consider the 
possibility of stripping from the stylesheet any whitespace node that has 
a following-sibling node that is an xsl:attribute element.

Thanks,

Henry
[Speaking on behalf of reviewers from IBM.]
------------------------------------------------------------------
Henry Zongaro      Xalan development
IBM SWS Toronto Lab   T/L 969-6044;  Phone +1 905 413-6044
mailto:zongaro@ca.ibm.com

Some discussion is recorded in the minutes...
DECISION: REJECTED.
      

Section 2.9

The last paragraph describes requirements on how error codes are treated. 
All specs in the XPath/XQuery/XSLT set should be consistant in their use 
of these error codes and whether they are prefixed or unprefixed.

Thanks,

Henry
[Speaking on behalf of reviewers from IBM.]
------------------------------------------------------------------
Henry Zongaro      Xalan development
IBM SWS Toronto Lab   T/L 969-6044;  Phone +1 905 413-6044
mailto:zongaro@ca.ibm.com

            
 
Status: no record of any discussion on this comment.

ACTION ITEM: Henry to either withdraw the comment or provide concrete
suggestions on how to improve the consistency.

========================================================
EXTRACT FROM MINUTES OF 15 JULY 2004

Other WG members do not see a need. Henry Z does not object to withdrawing
the comment. Action HZ to send email confirming this.

========================================================

            
         

Section 2.8

A compatibility flag on a stylesheet that would make construction of the 
data model in a schema-aware XSLT processor exactly the same as it would 
be in a basic XSLT processor should be required.

Thanks,

Henry
[Speaking on behalf of reviewers from IBM.]
------------------------------------------------------------------
Henry Zongaro      Xalan development
IBM SWS Toronto Lab   T/L 969-6044;  Phone +1 905 413-6044
mailto:zongaro@ca.ibm.com

An extensive discussion is recorded in the minutes, but there was

NO DECISION.
      

qt-2004Feb1067-01: [XSLT2.0] IBM-XSLT-105: Making a schema-aware processor behave as a basic processor
Long, trying discussion.  Consensus (i.e. no violent opposition) on:
Syntactic construct at stylesheet module level, three-values (yes, no, dontcare) 
or (keep-annotations, lose-annotations, dont-care), it's an error if one module 
says keep and one says lose, dont-care picks up keep or lose behavior from the
module(s) with values, if all are don'tcare then keep.
Concrete syntax: attribute on xsl:stylesheet element, possible name
default-input-validation, possible values preserve,
strip, whatever. Alternatives to
the third value: you-decide or lax.
Norm suggests validation-requirements or
input-validation-requirements.  MS suggests
input-type-annotations.  SCA suggests leaving it to the
editor.
Values?  MK suggests preserve, strip,
default.  AB suggests agnostic,
MS unspecified.
ACTION: editor to draft.
      

In 3.6, Stylesheet Element, add to the proforma:

input-type-annotations?="strip|preserve|unspecified"

Add a new section 4.3 as follows:

4.3 Stripping Type Annotations from a Source Tree

There is sometimes a requirement to write stylesheets that produce the same
results whether or not the source document has been validated against a
schema. To achieve this, an option is provided to remove any type
annotations on element and attribute nodes in the source document,
replacing them with an annotation of xs:untyped in the case of element
nodes, and xs:untypedAtomic in the case of attribute nodes.

Such stripping of type annotations can be requested by specifying
input-type-annotations="strip" on the xsl:stylesheet element. This attribute
has three permitted values: "strip", "preserve", and "unspecified". The
default value is "unspecified". Stripping of type annotations takes place if
at least one stylesheet module in the stylesheet specifies
input-type-annotations="strip". It is a static error [ERRXXXX] if there is a
module in the stylesheet that specifies input-type-annotations="strip" and
another module that specifies input-type-annotations="preserve".

The source documents to which this applies are the same as those affected by
xsl:strip-space and xsl:preserve-space: see [4.4]. Conceptually, a copy of
the relevant source document is created as if by means of the instruction
<xsl:copy-of select="$doc" validation="strip"/>, and the transformation
works on this copy of the document in place of the original.

Note that stripping type annotations does not necessarily return the
document to the state it would be in had validation not taken place. In
particular, any defaulted elements and attributes that were added to the
tree by the validation process will still be present.

Note also that stripping type annotations may prevent the use of the id()
function to access nodes by their ID values.


In section 4.4 (formerly 4.3) (Stripping Whitespace from a Source Tree) add:

[ERR XX] It is a recoverable dynamic error if there is an element in a
source document that satisfies all of the following conditions: (a) the type
annotation of the element is a simple type; (b) the element is the parent of
a whitespace text node; (c) the name of the element is not in the set of
whitespace-preserving element names. The recovery action is to preserve the
whitespace text node. [Note: this is defined as an error because stripping
whitespace from such an element could cause its value to become inconsistent
with its type annotation].

Stripping of type annotations (see section 4.3) happens before stripping of
whitespace, so this error will not occur in the case where type annotations
are stripped.


Michael Kay

            
 
5. "Switch"

   http://lists.w3.org/Archives/Member/w3c-xsl-wg/2004Jun/0085.html
   http://lists.w3.org/Archives/Member/w3c-xsl-wg/2004Jun/0098.html
   http://lists.w3.org/Archives/Member/w3c-xsl-wg/2004Jun/0099.html

ACCEPTED (with minor change - remove 2nd sentence in 3rd para of 4.3)

Remove "Conceptually, a copy of the relevant source document is created 
as if
by means of the instruction <xsl:copy-of select="$doc"
validation="strip"/>, and the transformation works on this copy of the
document in place of the original."

*** updates applied in draft U - MHK

            
         

Section 2.6

The last sentence of the last paragraph states, "Under these circumstances 
the processor may report any errors in an xsl:output or xsl:character-map 
declaration, but is not required to do so."  However, the last sentence of 
section 21.3 states, "A processor that does not claim conformance with the 
serialization feature must not signal an error merely because the 
stylesheet contains xsl:output or xsl:character-map declarations; these 
declarations should be ignored."

The text in 21.3 might be taken to mean that these declarations should not 
be checked for errors at all.  We believe what was really intended was 
that these declarations have no effect, but that the processor may still 
check them for errors.  If that is the case, the text in 21.3 should be 
clarified. 

Thanks,

Henry
[Speaking on behalf of reviewers from IBM.]
------------------------------------------------------------------
Henry Zongaro      Xalan development
IBM SWS Toronto Lab   T/L 969-6044;  Phone +1 905 413-6044
mailto:zongaro@ca.ibm.com

Confirmed that the intent is to allow checking but not require it. 

There was some feeling that "schema-level" checks should be encouraged
(testing that the attributes that appear are all allowed) but it's too
difficult to distinguish precisely which these tests are. So we accept the
comment that the text in 21.3 should be clarified, and that the intent is
that processors that are not performing serialization (either because they
don't support serialization, or because the user didn't request it on this
run) may perform all, some, or no checks on the xsl:output element at their
discretion.

COMMENT ACCEPTED.
      

ection 2.5.1

The first definition states "the processor keeps track of which nodes are 
being processed. . . ."

This should say "the processor keeps track of which items are being 
processed. . . ."

Thanks,

Henry
[Speaking on behalf of reviewers from IBM.]
------------------------------------------------------------------
Henry Zongaro      Xalan development
IBM SWS Toronto Lab   T/L 969-6044;  Phone +1 905 413-6044
mailto:zongaro@ca.ibm.com

Change accepted.

Change applied - MHK

Status changed to "announced"

Section 2.5

The penultimate paragraph states that "On entry to a stylesheet function, 
a new empty evaluation context is established."

Use of the word "empty" is potentially confusing - there are things in 
this new evaluation context.

Thanks,

Henry
[Speaking on behalf of reviewers from IBM.]
------------------------------------------------------------------
Henry Zongaro      Xalan development
IBM SWS Toronto Lab   T/L 969-6044;  Phone +1 905 413-6044
mailto:zongaro@ca.ibm.com

Agreed that the sentence is misleading, action on the editor to rephrase it.

COMMENT ACCEPTED.

** MHK: DONE
      

Section 2.1

The paragraph beneath the note specifies the requirements on a processor 
or on a stylesheet when the word "must" is used.  Something similar needs 
to be done for the words "should", "may", "required" or "recommended" is 
used need to be specified.

Thanks,

Henry
[Speaking on behalf of reviewers from IBM.]
------------------------------------------------------------------
Henry Zongaro      Xalan development
IBM SWS Toronto Lab   T/L 969-6044;  Phone +1 905 413-6044
mailto:zongaro@ca.ibm.com

Mark felt this was nit-picking. Scott felt it was important legalese. MHK to
check the RFC. Do we use the term SHOULD or MAY in relation to stylesheets? 

ACTION on MHK to report back on this.

Action done: see 
http://lists.w3.org/Archives/Member/w3c-xsl-wg/2004May/0082.html

There's nothing in RFC2119 that suggests how to identify the different
parties on whom a MUST or SHOULD obligation is being placed. This is why
we've got the sentence that indicates that a MUST sometimes applies to the
[implementor of the] processor, and sometimes to the [author of the]
stylesheet.

We do sometimes use SHOULD to place obligations on stylesheet authors, e.g.
in 3.4 "This media type SHOULD be used for an XML document ..."

So in my view it's appropriate to accept the comment and expand our
explanation of these terms in section 2.1. Specifically, I suggest changing
the relevant paragraph to read:


<quote>
In this specification the words MUST, MUST NOT, SHOULD, SHOULD NOT, MAY,
REQUIRED, and RECOMMENDED are to be interpreted as described in [RFC2119]. 

Where the phrase MUST, MUST NOT, or REQUIRED relates to the behavior of the
XSLT processor, then an implementation is not conformant unless it behaves
as specified, subject to the more detailed rules in 21 Conformance. 

Where the word MUST, MUST NOT, or REQUIRED relates to a stylesheet, then the
processor MUST enforce this constraint on stylesheets by reporting an error
if the constraint is not satisfied.

Where the phrase SHOULD, SHOULD NOT, or RECOMMENDED relates to a stylesheet,
then a processor MAY produce warning messages if the constraint is not
satisfied, but MUST NOT treat this as an error.
</quote>

Michael Kay
     

            
 
Current status: MHK was given an action.
This was done: see:
http://lists.w3.org/Archives/Member/w3c-xsl-wg/2004May/0082.html
The proposal was discussed on 2004-05-27, with no recorded conclusion.

ACCEPTED.

** changes made in draft U - MHK

            
         

Global

Use of the terms defined in RFC 2119 ought to be avoided in notes.  See, 
for instance, the third note in 11.1.2.

Thanks,

Henry
[Speaking on behalf of reviewers from IBM.]
------------------------------------------------------------------
Henry Zongaro      Xalan development
IBM SWS Toronto Lab   T/L 969-6044;  Phone +1 905 413-6044
mailto:zongaro@ca.ibm.com

Comment accepted.

** change made (15 instances) - MHK

Status changed to "announced"

It would be nice if deprecated attributes, such as disable-output-escaping, were 
set off in some way, say with italics or bold italics, in the spec.

For example:

<!-- Category: instruction -->
<xsl:value-of
   select? = expression
   separator? = { string }
   disable-output-escaping? = "yes" | "no">      <== BOLD ITALICS HERE
   <!-- Content: sequence-constructor -->
</xsl:value-of>

or even something like <span style="color:gray">...</span> or some such.

Mike Fitzgerald

Thanks for the comment. It will be considered by the WG.

I can't treat this as being purely editorial because we don't currently
have a well-defined concept of deprecation. We have other attributes
such as data-type on xsl:sort that are retained solely for backwards
compatibility, but which are not deprecated as such. We also need to be
very careful that typographical conventions must never be the only way
in which information is communicated.

Michael Kay

Michael Kay wrote:
> Thanks for the comment. It will be considered by the WG.

Good!

> I can't treat this as being purely editorial because we don't currently
> have a well-defined concept of deprecation. We have other attributes
> such as data-type on xsl:sort that are retained solely for backwards
> compatibility, but which are not deprecated as such.

I like how required attributes are bold; I also like the addition of ? in XSLT 
2.0 for optional attributes. Some sort of typographical mechanism, such as 
italics or a special color, for deprecated and backward compatible attributes 
would be a sight for sore eyes (sore from reading so many specs, that is).

> We also need to be very careful that typographical conventions must
 > never be the only way in which information is communicated.

Of course.

Mike

MK: we currently don't define what we mean by "deprecated". People think
that it's a formal term. NW if it isn't defined we shouldn't use it. ZR:
should say "not recommended" or "should not". MS: a formal definition would
include some kind of statement of intent that it is going to be removed. SB:
that's not the case with Java. SB: The intent of the comment is to highlight
the deprecation to readers of the spec.

MK: we could put it in square brackets or in grey and define it as meaning
"facility not recommended and may be withdrawn". 

COMMENT ACCEPTED.

** MHK: applied changes, including DTD and stylesheet changes; not tested.
      

In message

http://lists.w3.org/Archives/Public/public-qt-comments/2004Feb/1116.html

our ref: qt-2004Feb1116-01

Mike Fitzgerald requested that we consider adding notation for deprecated
attributes to the XSLT element proformas in the spec.

The XSL WG decided on 27 May to accept this suggestion, leaving the
editorial details to the editor. The suggestion is to put the relevant
attributes in square brackets, using a grayed font.

The change includes introducing a proper definition of what we mean for a
construct to be deprecated.

Mike, I trust you will be happy with this outcome.

Michael Kay
for the XSL WG

Section 11.1.4 contains the note:

It is not possible to define an alias for the XML namespace
http://www.w3.org/XML/1998/namespace because there is a specific
provision in [XML Namespaces 1.0] (see erratum NE05) that disallows the
use of this namespace URI with any prefix other than xml.

This note is incorrect. The following is quite legitimate, and even
useful:

<xsl:stylesheet xmlns:axml="alias-xml"...>

<xsl:namespace-alias stylesheet-prefix="axml" result-prefix="xml">

<xsl:template match="z">
  <lre axml:space="preserve">

  </lre>
</xsl:template>

The new rules for xsl:namespace-alias make it clear that this cannot
result in a namespace node being generated that binds the prefix axml to
the XML namespace http://www.w3.org/XML/1998/namespace, therefore the
constraint quoted in this note is not violated. Under the XSLT 1.0
rules, it would work provided the implementation was careful in its
choice of prefixes.

Michael Kay

COMMENT ACCEPTED.

** MHK: change made. Example added to the spec.
      

I am somewhat peeved and the restrictions on a processor claiming
basic level conformance - specifically not being allowed to assign
type annotation to attributes other than xdt:untypedAtomic.

This means, that having developed a processor to basic level
conformance, you cannot then develop it further towards full
schema-aware conformance, except in one fell swoop, as if you
implement on a step-by-step basis, you promptly lose the ability to
claim basic level conformance.
-- 
Colin Paul Adams
Preston Lancashire

Thank you for this comment. Personal response: The working group did think
quite carefully about whether to allow processors to choose their own
favourite point on the spectrum from a basic XSLT processor to a fully
schema-aware processor, and decided that interoperability was best served by
disallowing this.

In practice, of course, there is no ban on anyone offering a processor that
has two modes of operation: (a) as a conformant basic-level processor, and
(b) as a non-conformant "basic plus selected bits of schema-awareness"
processor.

Although the formal comments period has expired, this comment will be added
to the WG's agenda.

Michael Kay 

=============================================
EXTRACT FROM MINUTES OF 15 JULY 2004

Comment rejected, WG concerned about interoperability. Mike Kay to respond
to comment.

STATUS ON 13 AUG 2004: ISSUE DECIDED, MHK NEEDS TO COMMUNICATE THE DECISION
=============================================

=======================================================================
Decision communicated to originator on public-qt-comments, 20 AUG 2004
=======================================================================

Hello all,
 
I am finding the xml:base interaction with xslt 2.0 to be a bit vague,
as its is defined in the context of the construction of sequences and
result or temporary trees. Might be useful to have at least one example
on stylesheet element, as well as clarifying text with respect to the
following elements;
 
xsl:include
xsl:import
xsl:result-document
 
and possibly xsl:function ???
 
regards, Jim Fuller

Perhaps the commenter hasn't understood that this is defined indirectly via
the data model.

Found a "SHOULD NOT" in a note in 11.1.2 that should not (!) be in upper
case.

ACTION on MHK to draft an explanatory response asking if there are any
specific cases that cause problems. If the commenter doesn't push back this
will close the comment (as REJECTED).

** ACTION DONE: see
http://lists.w3.org/Archives/Public/public-qt-comments/2004May/0086.html
      

Jim, you commented at 

http://lists.w3.org/Archives/Public/public-qt-comments/2004Mar/0012.html

that you thought the XSLT 2.0 specification was "a bit vague" in its
handling of xml:base.

The WG looked at this comment yesterday evening and had trouble identifying
any problem in this area.

Relative URIs in xsl:include, xsl:import, document(), etc are resolved
relative to the base URI of the element on which they appear. I think the
spec says this clearly. It also, in relevant places, points to the Data
Model document for a description of the base URI property of a node. The
Data Model document explains how the xml:base attribute affects the base URI
of a node: not directly, but implicitly by reference to the InfoSet and XML
Base specifications.

The description of xs:result-document in 19.1 similarly explains that the
href attribute of this instruction is *not* resolved relative to the base
URI of this instruction, but relative to the "base output URI", which is a
value supplied by the caller when a transformation is fired off.

I appreciate that it may be difficult to follow all the threads at times,
but our job is to specify things unambiguously, not to write a tutorial. If
you feel there are any particular ambiguities in the document, we would be
grateful if you could point them out. Otherwise we will close the comment
with no action.

Regards,

Michael Kay
for the XSL WG 

our ref: qt-2004Mar0012-01

** no response received; issue marked as completed 2004-06-23 - MHK

POSTSCRIPT: the WG discussed base URI further in January 2005, and found that there were some gaps
that needed to be filled, for example the question of the base URI of a parentless element. The draft of
4 April 2005 addresses these issues.

One of my users (Ed Willink) has raised this interesting suggestion (I have
modified it slightly):

If the stylesheet specifies as="element(FOO)" which a non-schema-aware
processor currently rejects, then rather than reporting an error the
processor should instead fall back to treat it as "element()". Similarly,
as="QName?" should fall back to as="xdt:anyAtomicType?".

This would make it much easier to write stylesheets that work well both with
and without a schema-aware processor.

We could apply this purely at the XSLT level, or we could extend it to the
two XPath constructs that use a SequenceType (instance of, and treat as). In
all cases the effect would simply be to run with less type checking.

We could also extend this principle so that a non-schema-aware processor
ignores "type" and "validation" attributes, and xsl:import-schema, rather
than rejecting them. Perhaps such fallback behaviour should be explicitly
requested using the "switch" which we are still trying to invent.

Michael Kay

I think element(foo) should not be associated with the ISSD at all and
do what persons want it to mean. See
http://sqljunkies.com/WebLog/mrys/archive/2004/02/27/1339.aspx  for an
exposition.

And making this fallback part of XPath would break the intent of
instance of and treat as.

Best regards

Michael [Rys]
 

      Summary: various questions were raised:

[ANON]: but presumably I am using the "as" attribute because I depend on it.
MK: if you ignored the "as" attribute, it would simply reduce the amount of
checking done. [ANON]: you can't fall back to the nearest type if you don't know
anything about the schema.

Could one just ignore the attribute entirely? If it said as="some subtype of
float", and I pass in untyped atomic, no implicit conversion would happen,
and you end up with a value of a different type than you would otherwise. So
it's not just an assertion, it's causing implicit type conversion, and not
doing that is dangerous.

[ANON]: doesn't winged-horse come in here for how a non-schema-aware processor
should handle unknown types?

MK: I'm feeling this is too difficult.

The status quo is that a type not in the static context is an error. People
felt this was the right thing to do.


COMMENT REJECTED.
      

The rules in section 4.3 concerning whitespace stripping in source documents
do not define what is meant by a source document.

Traditionally in 1.0 these rules applied to the principal source document
and to documents loaded using the document() function. They did not apply to
documents supplied in stylesheet parameters or returned from extension
functions.

We need to decide what to do about documents returned by doc() or
collection(). It would make sense to apply the same rules as for document();
however, the semantics of doc() and collection() are not defined in the XSLT
specification, so this might be tricky.

Michael Kay

Candidates: principle source document, stylesheet parameters,
documents that come from document functions (fn:doc, fn:document,
fn:collection, etc.)

Proposal: principle source document, documents that come from fn:doc,
fn:document, and fn:collection

Henry expresses concern about query's reaction to stripping.

Consensus appears to be that whitespace stripping is a feature of the
host language.

Mike: We could redefine strip-space so that it's a hint to the parser.
If you don't have any control over that process, then it gets ignored.

Why doesn't this apply to result trees?

Conceptually, this is a post-process; you get a collection of
documents then you modify it.

Proposal: principle source document, documents that come from fn:doc,
fn:document, and fn:collection

Accepted.
     
      

In 5.4 we currently have a rule that says that evaluating the pattern "/"
against an orphan element node will not throw an error, but will return
false. 

I believe we need to generalize this rule so that all dynamic errors that
occur while evaluating a pattern are masked, and treated as if the pattern
returned false. This is because it is not possible for the user to predict
which patterns will be applied to which nodes, and writing patterns that
will never fail can be quite difficult. 

For example:

*	the pattern match='*[. = ""]' will give an error if applied to an
element whose typed value is a date, or to an element with element-only
content

Michael Kay

Some discussion. Serious concern that turning off error checking is
way too dangerous.

It's also a problem because you won't get any errors reported (e.g., if
you got the syntax of a regexp wrong).

Maybe just restrict it to type errors?

ANON: leave the status quo until we get to CR and see how bad the
problem really is. Maybe specific use cases will help us come up with
smaller bandages.

ANON: I'm concerned that we're making this language so hard to use
that it'll cease being an attractive solution to the problems it was
designed to solve.

ANON: Maybe the rules on the '=' operator should be changed so that
not-comparable means not equal. That would solve a lot of these
problems.

ANON: Maybe that solution will develop.

ACTION: Mike to raise changing the rules on the '=' operator globally.

** Email raised on xsl-query list (2004-06-03)
      

ACTION: Mike to raise changing the rules on the '=' operator globally.

ANON: This is for issue with raising errors in match patterns.
    Difficult to do this - sometimes you really would consider
    such an error to be an error; sometimes, it's just difficult 
    for the user to avoid an inadvertent error.
ANON: How about a global flag to control whether errors in
    patterns are detected?
ANON: Don't like optional features.  Perhaps a function that says,
    "evaluate my argument, returning the result if it succeeds;
    ignore errors, if it raises an error."  That limits scope
    of effect.
[Murmurs of approval for this approach from all.]
ANON: Could be spelt "try".


      

MK summarized his proposal 
at http://lists.w3.org/Archives/Member/w3c-xsl-wg/2004Jun/0077.html
Long discussion.  We took a straw poll: which of the proposals do you like?

try() (requires collaboration with Query): 5
ignore all type and dynamic errors on match patterns (i.e. no error, return false): 2
ignore type and dynamic errors on match patterns with flag at stylesheet level: 5
new attribute (on-match-error or something) on xsl:template: 2
new attribute (on-match-error or something) on several elements 
(first approximation: those with select attributes): 2
"try" as an operator
do nothing: 3


      

            
 
Status: Discussion at F2F in June favoured a try/catch proposal. Since that
requires joint work, MHK has proposed
http://lists.w3.org/Archives/Member/w3c-xsl-wg/2004Jun/0101.html as a way
forward.

   http://lists.w3.org/Archives/Member/w3c-xsl-wg/2004Jun/0077.html
   http://lists.w3.org/Archives/Member/w3c-xsl-wg/2004Jun/0101.html
   http://lists.w3.org/Archives/Member/w3c-xsl-wg/2004Jun/0096.html

Proposal:

Dynamic errors or type errors during evaluation of match pattern is
treated as recoverable error. (Mike's proposal in message
2004Jun/0101.html).

ACCEPTED without any objections.

** text updated in draft U (new section: errors in patterns) - MHK

Keep the try/catch orthogonal to errors in match pattern.

ACTION ITEM: Scott to draft a proposal on try catch.

            
         

We have aligned the formats used in format-date() with those used in
xsl:number. However, this overlooks the fact that components of the time can
have a value of zero, which cannot arise with xsl:number. A format of "01"
for minutes or seconds is reasonable, and should cause zero to be output as
"00". However, some other format tokens such as "I" and "a" don't make sense
with fields that allow zero values. The spec needs to say something about
this.

 

Michael Kay

(problem raised by a Saxon user)

Currently, xsl:number can't format '0' and that comes up frequently in
times.

Where it makes sense, we should make the formats in xsl:number capable
of formatting a number. In particular, '1', '01', etc.

The proposal would make it possible to format '0' in xsl:number.

Proposal: amend xsl:number so that it is capable of formatting zeros
for some formats. Create a minimum value just like there is now a
maximum value.

Accepted.

** MHK: spec updated.
      

I do not understand the rationale for the numeric datatypes permitted
for a basic processor. Could someone explain, please?

My thoughts are on the following lines:

The programmer ought to have the choice between accuracry and speed of
operation.

The former is represented by xs:decimal and xs:integer.
The latter by - well what?
I would have said xs:int and xs:float.
-- 
Colin Paul Adams
Preston Lancashire

Thanks for the comment. The public comment period has closed but we'll still
add this to the agenda if we can find time for it.

However: a personal response: 

(a) I think there are likely to be very few stylesheets whose performance
will benefit noticeably from using 32-bit rather than 64-bit arithmetic. If
you're going to trade correctness of output for speed of output, you need a
very clear view of how much performance you think you can gain by it.

(b) xs:integer and xs:decimal are types for which there are numeric literals
defined in the XPath syntax. Also, note that the result of adding two xs:int
values is an xs:integer value. They are therefore pretty fundamental. (Of
course, an xs:int is an xs:integer, so it's valid for an implementation to
return an xs:int as the result of 2+2. But it's not valid to give the wrong
answer if the result of the addition exceeds 32 bits.)

Michael Kay

** and see subsequent messages in thread.

Mike: The point seems to be that a literal gives you an xs:integer so
there'd be a lot of work to do to support xs:int without xs:integer.

Proposal: reject the comment.

Accepted.

** MHK: sent response 2004-06-03
      

Colin, you raised this comment at

http://lists.w3.org/Archives/Public/public-qt-comments/2004Mar/0218.html

our ref: +qt-2004Mar0218-01 

The Working Group discussed this comment today, and decided to make no
change to the specification.

Broadly, the WG endorsed my earlier informal response. The minimum set of
types that an XSLT processor must support has to relate to the types that
are primitive in XML Schema and in XPath (e.g. the types for which literals
are defined) and the types used by the function library. For example, since
position() returns an xs:integer, the set has to include xs:integer.

Implementators are free to offer the full set of types if they think that
users need them.

Please let us know if you can accept this resolution of the comment.

Thanks for the contribution.

Michael Kay
for the XSL WG

  I am happy to accept this resolution, now I understand matters better.
-- 
Colin Paul Adams
Preston Lancashire

In XSL WG discussions of issue qt-2004Feb0625-01 (see [1]) a separate
problem emerged: it is not safe to preserve the type annotation of an
attribute when the attribute is copied (using xsl:copy or xsl:copy-of),
because there is no guarantee that the namespace context of the new
attribute will be the same. This affects the outcome if the attribute value
is an xs:QName.

This also raises questions about the precise meaning of xsl:copy[-of] when
applied to QName-valued attributes - does it copy the typed value or the
string value? In the first case, the namespace prefix of the QName value is
lost, in the second case, the namespace URI is lost.

There are similar discussions affecting the semantics of attribute copying
in XQuery, so this is a joint issue.


[1] http://lists.w3.org/Archives/Public/public-qt-comments/2004Feb/0625.html

========================================================
EXTRACT FROM MINUTES OF 15 JULY 2004 TELCON

The underlying problem is the "triples" question.
Add note that the typed value has information that is not present in
the string value and that the implementation may need to preserve
additional information (akin to "triples proposal")?

Karun and Norm think we should wait until triples proposal has been
accepted - we are rather dependent on our "infrastructure"...
Resolution to be based on the publication plans.
=========================================================

=========================================================
CLOSED BY MHK 20 AUG 2004
The problem is believed to be solved by virtue of the triples proposal.
Email sent to xsl-wg explaining this conclusion.
=========================================================

An extra parameter has been added to the id() function to identify the
target document. 

We need to decide whether to make the same change to XSLT's key() 
function.

Michael Kay

*** Follow-up from Dimitre Novatchev (23 Mar 2004)

This would be very nice! Having to use more than one key on different
documents leads to sprinkling of lots of artificial xsl:for-each
instructions and this results in code that is very difficult to read and
understand even by its original author. It is especially difficult to
decide what the current document is at particular point of the code. I had
a recent bad experience exactly with this.

Please, do include the proposed new argument -- this will make
programmer's work a lot easier and the code much more readable, 
understandable and maintainable.

This should be a separate overload, preserving an overload with the
current signature of the key() function.


With regards,

Dimitre Novatchev.

This isn't strictly necessary, since you can do $doc/key(), but since
we added the parameter to id() we should add it to key(). And the
$doc/key() syntax is a bit obscure.

Proposal: add the second parameter to key()

Accepted.

MK: added the function prototype to the spec, and an ednote as a place-holder for the semantics.

POSTSCRIPT: subsequently, having added the third argument to the key() function, the WG realized it
could be made more useful if it restricted the scope of the search to a subtree rooted at the node
identified by the third argument.

      

Section 7 of XSLT 2.0

The first bullet in this section states that "If it is not a node, there 
will be no context node: that is, the value of self::node() will be an 
empty sequence."  However, the third paragraph of section 3.2.1 of XPath 
2.0 states that, for an axis step, "If the context item is not a node, a 
type error is raised.[err:XP0020]"

The text in XSLT should be amended to indicate that self::node() will 
raise a type error in the situation described.

Thanks,

Henry
------------------------------------------------------------------
Henry Zongaro      Xalan development
IBM SWS Toronto Lab   T/L 969-6044;  Phone +1 905 413-6044
mailto:zongaro@ca.ibm.com

Proposal: correct the text so that self:node() raises an error in that case.

Accepted.

MHK: spec updated.
      

Section 18.1.1 of XSLT 2.0

The third paragraph beneath the signature of function-available states 
that "The value of the $function-name argument must be a string containing 
a lexical QName.  If the lexical QName is unprefixed, then the standard 
function namespace is used in the expanded QName."  The last sentence of 
the paragraph then says, "If the expanded-QName has a non-null namespace 
URI, then it refers to a stylesheet function or extension function; 
otherwise, it refers to a function defined by XPath or XSLT."

The first part of the paragraph precludes the possibility that the 
expanded-QName will ever have a null namespace URI.  The last sentence of 
the paragraph should be changed to "If the namespace URI of the 
expanded-QName is the standard function namespace, the expanded-QName 
refers to a function defined by XPath or XSLT; otherwise, it refers to a 
stylesheet function or extension function."

Thanks,

Henry
------------------------------------------------------------------
Henry Zongaro      Xalan development
IBM SWS Toronto Lab   T/L 969-6044;  Phone +1 905 413-6044
mailto:zongaro@ca.ibm.com

Proposal: the comment is correct, make the change.

Accepted.

MHK: the offending text had already been deleted from the spec.
      

Appendix B1 states:

     This media type registration is for XSLT stylesheet modules as 
described by this specification.
Applications which use this media type:

     Some authors have already started to write XSLT 2.0 documents. 
However that content is currently most often described using the 
unregistered media type "text/xslt".

     There is no experimental, vendor specific, or personal tree 
predecessor to "application/xslt+xml", reflecting the fact that no 
applications currently recognize it. This new type is being 
registered in order to allow for the expected deployment of XSLT 2.0 
on the World Wide Web, as a first class XML application.

I have two problems with this. The first is minor. I have never seen 
"text/xslt" used anywhere. Microsoft uses text/xsl" without the final 
t.

The second is much more major. This registration should not be 
limited to XSLT 2. It is needed for XSLT 1.0 as well. The current 
language strongly implies that this media type is only acceptable for 
XSLT 2.0 stylesheets.

RFC 3023 does not restrict application/xslt+xml to XSLT 2.0.

-- 

   Elliotte Rusty Harold
   elharo@metalab.unc.edu
   Effective XML (Addison-Wesley, 2003)
   http://www.cafeconleche.org/books/effectivexml            
   http://www.amazon.com/exec/obidos/ISBN%3D0321150406/ref%3Dnosim/cafeaulaitA 

Elliotte,

This is a response from the XSL WG to your comment at
http://lists.w3.org/Archives/Public/public-qt-comments/2004May/0057.html

The XSL WG discussed your comment and agreed with it. We will change the
text of the proposed MIME type registration:

(a) to say that the unregistered type in popular use is currently "text/xsl"

(b) to make it clear that the proposed type "application/xslt+xml" is
intended to apply to all versions of XSLT.

I trust that this meets with your approval.

Michael Kay
for the XSL Working Group

Michael Kay wrote:

>Elliotte,
>
>This is a response from the XSL WG to your comment at
>http://lists.w3.org/Archives/Public/public-qt-comments/2004May/0057.html
>
>The XSL WG discussed your comment and agreed with it. We will change the
>text of the proposed MIME type registration:
>
>(a) to say that the unregistered type in popular use is currently "text/xsl"
>
>(b) to make it clear that the proposed type "application/xslt+xml" is
>intended to apply to all versions of XSLT.
>
>I trust that this meets with your approval.
>  
>


It does. Thanks.

--
Elliotte