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

Last Call Comments 2005-04-04

Editor :
Michael Kay

Last Call issues on XSLT 2.0

There are 108 issues of which 108 are completed.

Issues by type: substantive ( 76 ) typo ( 9 ) question ( 11 ) editorial ( 12 )

Issues by closure category: explanation ( 4 ) rejected ( 22 ) accepted-editorial ( 27 ) accepted-clarification ( 35 ) accepted-newfunctionality ( 14 ) accepted-bug ( 6 )

Issues by last movement: acknowledged ( 27 ) decided ( 44 ) discussed ( 14 ) announced ( 16 ) raised ( 3 ) proposed ( 4 )

Id Title Type State Disposition
+qt-2003Nov0052-01 Incremental transformations substantive completed explanation
+qt-2003Nov0055-01 format-dateTime localised picture parameters long medium short substantive completed rejected
+qt-2003Nov0315-01 [XSLT2.0] Example: Using Tunnel Parameters typo completed accepted-editorial
+qt-2003Nov0301-01 [XSLT2.0] format-date() - country substantive completed rejected
+qt-2003Nov0317-01 [XSLT2.0] 20.2 Example: Interaction of Output Escaping and CDATA typo completed accepted-editorial
+qt-2003Dec0117-01 unique IDs for fn:id() and interaction with XSLT temporary trees question completed explanation
+qt-2003Dec0115-01 [XSLT2.0] K.1.2 Incompatibility in the Absence of a Schema typo completed accepted-editorial
+qt-2003Dec0120-01 [XSLT2.0] XML versions and XSLT stylesheet as a data model instance substantive completed accepted-clarification
+qt-2003Dec0130-01 [XSLT2.0] fragment identifiers, media types and document() editorial completed accepted-clarification
+qt-2003Dec0166-01 [XSLT2.0] 16.6.5 system-property substantive completed rejected
+qt-2003Dec0165-01 [XSLT2.0] 21.1 Basic XSLT Processor substantive completed accepted-newfunctionality
+qt-2004Jan0010-01 [XSLT2.0] value-of and backwards compatibility substantive completed rejected
+qt-2004Jan0008-01 [XSLT2.0] OB04, 5.6.3 Namespace Fixup, QNames in content question completed accepted-clarification
+qt-2004Jan0014-02 Creating text nodes in XSLT question completed rejected
+qt-2004Jan0013-01 [XSLT] Replace reference to RFC 1738 substantive completed accepted-editorial
+qt-2004Jan0021-01 [XSLT2.0] Collations with lang and case-order question completed accepted-clarification
+qt-2004Jan0019-01 [XSLT2.0] Consistent Rules on Import Precedence substantive completed accepted-newfunctionality
+qt-2004Jan0019-02 [XSLT2.0] Consistent rules for lang attribute substantive completed rejected
+qt-2004Jan0019-03 [XSLT2.0] Add lang attribute to xsl:decimal-format substantive completed rejected
+qt-2004Jan0019-04 [XSLT2.0] Specify normalization form for serialization substantive completed accepted-newfunctionality
+qt-2004Jan0350-01 [XSLT 2.0] Type Consistency for Overridden Definitions substantive completed rejected
+qt-2004Jan0343-01 [XSLT2.0] xsl:output-character, additional attributes (SMITH 01) substantive completed rejected
+qt-2004Jan0424-01 [XSLT2] OB06 xsl:analyze-string substantive completed rejected
+qt-2004Feb0105-01 Error in xsl:namespace example typo completed accepted-editorial
+qt-2004Feb0129-01 [XSLT 2.0] Reclassification of Dynamic Errors substantive completed rejected
+qt-2004Feb0128-01 [XSLT 2.0] Inheriting Namespace Nodes substantive completed accepted-newfunctionality
+qt-2004Feb0127-01 [XSLT 2.0] unparsed-text() signature substantive completed accepted-editorial
+qt-2004Feb0126-01 [XSLT 2.0] Union operator in patterns substantive completed accepted-newfunctionality
+qt-2004Feb0125-01 [XSLT 2.0] format-number() - rounding large numbers substantive completed accepted-bug
+qt-2004Feb0124-01 [XSLT 2.0] Error in published schema for XSLT 2.0 substantive completed accepted-bug
+qt-2004Feb0111-01 [XSLT2.0] Binding of a local xsl:variable or xsl:param by another local xsl:variable/xsl:param substantive completed rejected
+qt-2004Feb0160-01 parametrized result-document substantive completed accepted-newfunctionality
+qt-2004Feb0168-01 [XSLT 2.0] limits on numbering sequences substantive completed accepted-clarification
+qt-2004Feb0255-01 [XSLT2.0] XML Schema WG Comment 2/2 [typo] typo completed accepted-editorial
+qt-2004Feb0253-01 [XSLT2.0] XML Schema WG Comment 1/2 [datatypes namespace] substantive completed accepted-bug
+qt-2004Feb0625-01 ORA-XS-379-Q: ERR XT0955 substantive completed accepted-newfunctionality
+qt-2004Feb0624-01 ORA-XS-365-B: Current Captured Substrings missing in XPath Context substantive completed accepted-clarification
+qt-2004Feb0622-01 ORA-XS-381-Q: Stable Sorting Performance substantive completed accepted-newfunctionality
+qt-2004Feb0621-01 ORA-XS-367-C: Missing Parameter error editorial completed accepted-editorial
+qt-2004Feb0620-01 ORA-XS-370-B: Signature of function-available() substantive completed accepted-newfunctionality
+qt-2004Feb0619-01 ORA-XS-380-B: ERR XT1000 is a Dynamic Error typo completed rejected
+qt-2004Feb0618-01 ORA-XS-369-B: whitespace or space typo completed accepted-clarification
+qt-2004Feb0617-01 ORA-XS-364-B: Current Group Key missing in XPath Context substantive completed accepted-clarification
+qt-2004Feb0615-01 ORA-XS-384-B: Current Group missing in XPath Context substantive completed accepted-editorial
+qt-2004Feb0613-01 ORA-XS-362-Q: Consistency of "as" Attribute substantive completed accepted-newfunctionality
+qt-2004Feb0610-01 ORA-XS-360-B: Bug in 1st example typo completed accepted-editorial
+qt-2004Feb0607-01 ORA-XS-359-C: terminology editorial completed accepted-editorial
+qt-2004Feb0581-01 ORA-XS-356-B: <xsl:apply-templates select="*" /> editorial completed accepted-editorial
+qt-2004Feb0580-01 ORA-XS-357-B: #current editorial completed accepted-editorial
+qt-2004Feb0579-01 ORA-XS-358-B: additional XPath dynamic context components substantive completed accepted-clarification
+qt-2004Feb0575-01 ORA-XS-350-E: xs:NMTOKENS vs. xdt:untypedAtomic substantive completed accepted-editorial
+qt-2004Feb0574-01 ORA-XS-351-E: Mapping from URIs to media types substantive completed accepted-clarification
+qt-2004Feb0571-01 ORA-XS-319-C: Stylesheet Evaluation Context Clarification editorial completed accepted-clarification
+qt-2004Feb0570-01 ORA-XS-323-Q: Prepending Nodes substantive completed accepted-clarification
+qt-2004Feb0569-01 ORA-XS-348-E: An element which can be both instruction and declaration editorial completed accepted-editorial
+qt-2004Feb0568-01 ORA-XS-325-C: Title Clarification substantive completed accepted-editorial
+qt-2004Feb0572-01 ORA-XS-324-Q: Recomendation for Additional Mode Attribute substantive completed rejected
+qt-2004Feb0567-01 ORA-XS-349-C: Using Base output URI substantive completed accepted-editorial
+qt-2004Feb0559-01 ORA-XS-313-C: Comments about the XSLT 2.0 concepts. substantive completed accepted-clarification
+qt-2004Feb0560-01 ORA-XS-316-C: Definition clarification substantive completed accepted-editorial
+qt-2004Feb0558-01 ORA-XS-318-C: Initial Value of Evaluation Context Clarification question completed accepted-clarification
+qt-2004Feb0556-01 ORA-XS-354-E: Item 3 editorial completed accepted-editorial
+qt-2004Feb0691-01 request, unparsed-entity-references substantive completed explanation
+qt-2004Feb0856-01 [XSLT20] Backward Compatibility substantive completed accepted-newfunctionality
+qt-2004Feb0990-01 new Feature needed [Dynamic XPath Evaluation] substantive completed rejected
+qt-2004Feb1007-01 [XSLT] Validation mode preserve (technical) substantive completed accepted-editorial
+qt-2004Feb1089-01 [XSLT2.0] IBM-XSLT-127: XSLT 2.0 last call editorial comments editorial completed accepted-editorial
+qt-2004Feb1088-01 [XSLT2.0] IBM-XSLT-126: Organization of Section K substantive completed accepted-editorial
+qt-2004Feb1087-01 [XSLT2.0] IBM-XSLT-125: Need to state that an XSLT processor must support all F&O functions substantive completed accepted-clarification
+qt-2004Feb1086-01 [XSLT2.0] IBM-XSLT-124: Default output methods of final result trees should be independent of each other question completed accepted-clarification
+qt-2004Feb1085-01 [XSLT2.0] IBM-XSLT-123: Description of when default output method is used substantive completed accepted-clarification
+qt-2004Feb1084-01 [XSLT2.0] IBM-XSLT-122: Errors for result document URI conflicts substantive completed accepted-clarification
+qt-2004Feb1083-01 [XSLT2.0] IBM-XSLT-121: Dynamic errors for references to extension functions substantive completed accepted-clarification
+qt-2004Feb1082-01 [XSLT2.0] IBM-XSLT-120: Formatting date/time components by name substantive completed accepted-clarification
+qt-2004Feb1081-01 [XSLT2.0] IBM-XSLT-119: Obligations for unparsed-text function editorial completed accepted-editorial
+qt-2004Feb1080-01 [XSLT2.0] IBM-XSLT-118: Problems with using document('') to refer to stylesheet substantive completed accepted-clarification
+qt-2004Feb1079-01 [XSLT2.0] IBM-XSLT-117: How is value of select in xsl:analyze-string converted to string? question completed accepted-clarification
+qt-2004Feb1078-01 [XSLT2.0] IBM-XSLT-116: Supported combinations of ordinal numbering substantive completed accepted-clarification
+qt-2004Feb1077-01 [XSLT2.0] IBM-XSLT-115: Encourage use of prefix of lexical QName for xsl:element substantive completed rejected
+qt-2004Feb1076-01 [XSLT2.0] IBM-XSLT-114: Change in behaviour from XSLT 1.0 for namespace aliasing substantive completed rejected
+qt-2004Feb1075-01 [XSLT2.0] IBM-XSLT-113: Namespace and attribute nodes and document order question completed accepted-clarification
+qt-2004Feb1074-01 XSLT2.0] IBM-XSLT-112: Reference to "unknown" function should be non-recoverable question completed accepted-clarification
+qt-2004Feb1073-01 XSLT2.0] IBM-XSLT-111: Implications of using "as" attribute question completed accepted-clarification
+qt-2004Feb1072-01 [XSLT2.0] IBM-XSLT-110: disable-output-escaping on xsl:attribute typo completed accepted-editorial
+qt-2004Feb1071-01 [XSLT2.0] IBM-XSLT-109: Typed data and backwards compatibility substantive completed accepted-clarification
+qt-2004Feb1070-01 [XSLT2.0] IBM-XSLT-108: Whitespace stripping optimization substantive completed accepted-clarification
+qt-2004Feb1069-01 [XSLT2.0] IBM-XSLT-107: Should xml:space have no effect before xsl:attribute? substantive completed rejected
+qt-2004Feb1068-01 [XSLT2.0] IBM-XSLT-106: Consistent treatment of errors in XPath/XQuery/XSLT specs. substantive completed rejected
+qt-2004Feb1067-01 [XSLT2.0] IBM-XSLT-105: Making a schema-aware processor behave as a basic processor substantive completed accepted-newfunctionality
+qt-2004Feb1066-01 [XSLT2.0] IBM-XSLT-104: Ignoring xsl:output and xsl:character-map substantive completed accepted-clarification
+qt-2004Feb1065-01 [XSLT2.0] IBM-XSLT-103: Focus keeps track of items editorial completed accepted-editorial
+qt-2004Feb1064-01 [XSLT2.0] IBM-XSLT-102: "Empty evaluation context" is confusing substantive completed accepted-clarification
+qt-2004Feb1063-01 [XSLT2.0] IBM-XSLT-101: Implications of RFC 2119 terms for processors and stylesheets substantive completed accepted-clarification
+qt-2004Feb1062-01 [XSLT2.0] IBM-XSLT-100: Use of RFC 2119 terms in notes editorial completed accepted-editorial
+qt-2004Feb1116-01 [XSLT 2.0] setting off deprecated attributes substantive completed accepted-editorial
+qt-2004Feb1130-01 [XSLT2.0] Aliasing the XML Namespace substantive completed accepted-clarification
+qt-2004Feb1237-01 [XSLT 2.0] Conformance levels substantive completed rejected
+qt-2004Mar0012-01 [XSLT2.0] xml:base interaction question completed explanation
+qt-2004Mar0075-01 [XSLT 2.0] Fallback for "as" attribute in non-schema-aware processor substantive completed rejected
+qt-2004Mar0077-01 [XSLT 2.0] Whitespace stripping in source documents substantive completed accepted-clarification
+qt-2004Mar0083-01 [XSLT 2.0] Dynamic errors in patterns substantive completed accepted-clarification
+qt-2004Mar0156-01 [XSLT2.0] formatting zero components of a dateTime substantive completed accepted-newfunctionality
+qt-2004Mar0218-01 [XSLT 2.0] Data types for a Basic XSLT processor substantive completed rejected
+qt-2004Mar0232-01 [XSLT 2.0] validation=preserve when copying attribute nodes substantive completed accepted-bug
+qt-2004Mar0233-01 [XSLT 2.0] Extra parameter for key() substantive completed accepted-newfunctionality
+qt-2004Apr0129-01 [XSLT 2.0] IBM-XSLT-128: behaviour of self::node() if there is no context node substantive completed accepted-bug
+qt-2004Apr0130-01 [XSLT 2.0] IBM-XSLT-129: Default function namespace for function-available substantive completed accepted-bug
+qt-2004May0057-01 [XSLT2.0] MIME type registartion substantive completed accepted-clarification
qt-2003Nov0052-01: Incremental transformations
[substantive, acknowledged] 2004-01-26
Incremental transformations, Cameron McCormack <cam-public-qt-comments@aka.mcc.id.au> (2003-11-12) 


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
Incremental transformations, Michael Kay (2004-01-20) 
            

**Action MK:  Indicate WG endorsed MK's earlier response rejecting
              the proposal, explaining WG's thinking.
Incremental transformations, Michael Kay (2004-01-25) 
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
Incremental transformations, Michael Kay (2004-01-25) 
         Change status to "announced"
Incremental transformations, (2004-01-26) 
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
qt-2003Nov0055-01: format-dateTime localised picture parameters long medium short
[substantive, decided] 2004-06-22
format-dateTime localised picture parameters long medium short, Richard Zschech <richard.zschech@cqrdata.com> (2003-11-13) 

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.
format-dateTime localised picture parameters long medium short, Michael Kay (2004-01-20) 
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
format-dateTime localised picture parameters long medium short, Michael Kay (2004-01-20) 
            
 
**Action MK:  Respond to this rejecting proposal, explaining WG's
              rationale.
format-dateTime localised picture parameters long medium short, Michael Kay (2004-01-25) 
         Status changed to "announced".
format-dateTime localised picture parameters long medium short, (2005-01-26) 
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.
Minutes of XSL WG 10 June 2004 Telcon, Henry Zongaro (2004-06-10) 

      Summary: The WG discussed various approaches including the idea of using system properties.
        MK took an action to develop a proposal.
XSLT Face-to-Face Minutes - 22 June 2004, Michael Sperberg-McQueen (2004-06-22) 
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
qt-2003Nov0315-01: [XSLT2.0] Example: Using Tunnel Parameters
[typo, acknowledged] 2004-01-16
[XSLT2.0] Example: Using Tunnel Parameters, David Carlisle <davidc@nag.co.uk> (2003-11-26) 
<xsl:template match="equation">
  <xsl:param name="equation-format" select="'(1)'" tunnel="yes"/>
  <xsl:number level="any" format="{$format}"/>
typo:
                                    $equation-format
</xsl:template>
[XSLT2.0] Example: Using Tunnel Parameters, Michael Kay (2004-01-15) 
            
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.
[XSLT2.0] Example: Using Tunnel Parameters, Michael Kay (2004-01-15) 
Status changed to "announced"
[XSLT2.0] Example: Using Tunnel Parameters, Michael Kay (2004-01-16) 
Status changed to "acknowledged"
qt-2003Nov0301-01: [XSLT2.0] format-date() - country
[substantive, decided] 2004-06-22
[XSLT2.0] format-date() - country, Mikael Sterner <msterner@kth.se> (2003-11-26) 


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
[XSLT2.0] format-date() - country, Michael Kay (2003-11-27) 
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
[XSLT2.0] format-date() - country, Michael Kay (2004-01-20) 
            
 
Action AB:  produce a draft response.
[XSLT2.0] format-date() - country, Michael Kay (2004-02-10) 

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.
[XSLT2.0] format-date() - country, Michael Kay (2004-02-12) 
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
[XSLT2.0] format-date() - country, Michael Kay (2004-02-12) 
        Status changed to "announced".
Minutes of XSL WG 10 June 2004 Telcon, Henry Zongaro (2004-06-10) 

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

ACTION: Anders Berglund to confirm that this issue is in fact closed.
XSLT Face-to-Face Minutes - 22 June 2004, Michael Sperberg-McQueen (2004-06-22) 
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
qt-2003Nov0317-01: [XSLT2.0] 20.2 Example: Interaction of Output Escaping and CDATA
[typo, acknowledged] 2004-01-16
[XSLT2.0] 20.2 Example: Interaction of Output Escaping and CDATA, David Carlisle <davidc@nag.co.uk> (2003-11-27) 




The example states that the output should be:

&lt;title&gt;&lt;![CDATA[This is not ]]&gt;&lt;hr/&gt;&lt;![CDATA[ good coding practice]]&gt;&lt;/title&gt;


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
[XSLT2.0] 20.2 Example: Interaction of Output Escaping and CDATA, Michael Kay (2004-01-15) 
            
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.
[XSLT2.0] 20.2 Example: Interaction of Output Escaping and CDATA, Michael Kay (2004-01-15) 
Status changed to "announced"
[XSLT2.0] 20.2 Example: Interaction of Output Escaping and CDATA, Michael Kay (2004-01-16) 
Status changed to "acknowledged"
qt-2003Dec0117-01: unique IDs for fn:id() and interaction with XSLT temporary trees
[question, acknowledged] 2004-01-25
unique IDs for fn:id() and interaction with XSLT temporary trees, Mike Brown <mike@skew.org> (2003-12-09) 

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
unique IDs for fn:id() and interaction with XSLT temporary trees, Michael Kay (2004-01-20) 
            
DECISION: MK will explain to the commentor and evaluate whether to include in spec.
unique IDs for fn:id() and interaction with XSLT temporary trees, Michael Kay (2004-01-25) 
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
unique IDs for fn:id() and interaction with XSLT temporary trees, Michael Kay (2004-01-25) 
Status changed to "announced"
unique IDs for fn:id() and interaction with XSLT temporary trees, Mike B (2004-01-25) 
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
qt-2003Dec0115-01: [XSLT2.0] K.1.2 Incompatibility in the Absence of a Schema
[typo, acknowledged] 2004-01-16
[XSLT2.0] K.1.2 Incompatibility in the Absence of a Schema, David Carlisle <davidc@nag.co.uk> (2003-12-09) 


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

which is not well formed.

David
[XSLT2.0] K.1.2 Incompatibility in the Absence of a Schema, Michael Kay (2004-01-15) 
            
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.
[XSLT2.0] K.1.2 Incompatibility in the Absence of a Schema, Michael Kay (2004-01-15) 
Changed status to "announced"
[XSLT2.0] K.1.2 Incompatibility in the Absence of a Schema, Michael Kay (2004-01-16) 
Changed status to "acknowledged"
qt-2003Dec0120-01: [XSLT2.0] XML versions and XSLT stylesheet as a data model instance
[substantive, raised] 2004-06-22
[XSLT2.0] XML versions and XSLT stylesheet as a data model instance, David Carlisle <davidc@nag.co.uk> (2003-12-10) 



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
[XSLT2.0] XML versions and XSLT stylesheet as a data model instance, Michael Kay (2003-12-10) 
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
[XSLT2.0] XML versions and XSLT stylesheet as a data model instance, Michael Kay (2004-01-20) 
            
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.
Minutes of XSL WG 10 June 2004 Telcon, Henry Zongaro (2004-06-10) 

> 2003Dec0120-01 Stylesheet as data model instance
> 
>    Agreed in principle, action on editor to come up with the wording
XSLT Face-to-Face Minutes - 22 June 2004, Michael Sperberg-McQueen (2004-06-22) 
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.

==================================================================
qt-2003Dec0130-01: [XSLT2.0] fragment identifiers, media types and document()
[editorial, acknowledged] 2004-06-22
[XSLT2.0] fragment identifiers, media types and document(), David Carlisle <davidc@nag.co.uk> (2003-12-11) 



> 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
[XSLT2.0] fragment identifiers, media types and document(), Michael Kay (2003-12-10) 

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

Michael Kay
[XSLT2.0] fragment identifiers, media types and document(), Michael Kay (2004-01-20) 
            
  
**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.
[XSLT2.0] fragment identifiers, media types and document(), Michael Kay (2004-01-20) 
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
[XSLT2.0] fragment identifiers, media types and document(), Michael Kay (2004-01-25) 
Changed status to "announced"
[XSLT2.0] fragment identifiers, media types and document(), (2004-01-25) 
> 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
XSLT Face-to-Face Minutes - 22 June 2004, Michael Sperberg-McQueen (2004-06-22) 
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.
qt-2003Dec0166-01: [XSLT2.0] 16.6.5 system-property
[substantive, acknowledged] 2004-03-01
[XSLT2.0] 16.6.5 system-property, David Carlisle <davidc@nag.co.uk> (2003-12-17) 



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
[XSLT2.0] 16.6.5 system-property, Michael Kay (2003-12-17) 


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.
[XSLT2.0] 16.6.5 system-property, Michael Kay (2004-01-20) 
            
    
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.
[XSLT2.0] 16.6.5 system-property, Michael Kay (2004-01-20) 
            
    
*Action NW:  Respond rejecting proposal and giving rationale for current
              behaviour

	      
	      
*MHK announced decision on 1 Mar 2004
re: [XSLT2.0] 16.6.5 system-property, Michael Kay (2004-03-01) 
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
Re: [XSLT2.0] 16.6.5 system-property, David Carlisle (2004-03-01) 

>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
qt-2003Dec0165-01: [XSLT2.0] 21.1 Basic XSLT Processor
[substantive, acknowledged] 2004-12-13
[XSLT2.0] 21.1 Basic XSLT Processor, David Carlisle <davidc@nag.co.uk> (2003-12-17) 


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
[XSLT2.0] 21.1 Basic XSLT Processor, Michael Kay (2004-01-20) 
            
ACTION ITEM: MK will produce a proposal on this covering related areas as well. 
             Add a "guard" attribute to xsl:if and xsl:when.
[XSLT2.0] 21.1 Basic XSLT Processor, Michael Kay (2004-02-04) 
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
[XSLT 2.0] Extension functions with side-effects and optimizations, Michael Kay (2004-01-04) 


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
[XSLT 2.0] Extension functions with side-effects and optimizations, Michael Kay (2004-01-15) 
            
(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.
[XSLT 2.0] Extension functions with side-effects and optimizations, Michael Kay (2004-01-20) 
            
**Action MK:  Respond confirm MK's earlier provisional response.
              And strengthen wording in spec.
[XSLT 2.0] Extension functions with side-effects and optimizations, Michael Kay (2004-01-25) 

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
[XSLT 2.0] Extension functions with side-effects and optimizations, Michael Kay (2004-12-13) 
Changed status to "announced"
[XSLT 2.0] Extension functions with side-effects and optimizations, Kenneth Stephen y2kmvs@us.ibm.com (2004-12-13) 
      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
qt-2004Jan0010-01: [XSLT2.0] value-of and backwards compatibility
[substantive, announced] 2004-06-24
[XSLT2.0] value-of and backwards compatibility, Niko Matsakis, DataPower (2004-01-06) 

I am writing to