W3C home > Mailing lists > Public > public-qt-comments@w3.org > November 2003

F&O fn:escape-uri

From: Ashok Malhotra <ashokma@microsoft.com>
Date: Mon, 10 Nov 2003 06:05:07 -0800
Message-ID: <EDB607C8AC991F40BE646533A1A673E8923678@RED-MSG-42.redmond.corp.microsoft.com>
To: "C. M. Sperberg-McQueen" <cmsmcq@acm.org>, <public-qt-comments@w3.org>, <w3c-i18n-ig@w3.org>
Cc: "W3C XML Schema IG" <w3c-xml-schema-ig@w3.org>, <aphillips@webmethods.com>, <duerst@w3.org>

Comment 2.8 in XML Schema WG comments on Functions and Operators (below) said:

    The rules for escaping URIs should be aligned across all W3C
    specifications; otherwise, we will drive our users crazy.

    We think that means that you should reference and implement the
    algorithm specified in the XML Linking specification
    ([30]http://www.w3.org/TR/2001/REC-xlink-20010627/#link-locators)

There was a similar comment from the i18N WG.

We agreed to align the description with the above algorithm which says that all characters disallowed in URIs according to RFC 2396 except for the number sign (#) and percent sign (%).  Thus, the number sign (#) and percent sign (%) are never escaped.

The forthcoming URI syntax draft http://gbiv.com/protocols/uri/rev-2002/rfc2396bis.html adds the number sign (#) to the list of reserved characters so it seems that it should be escaped.  This would be at variance with the Linking spec but seems to be the correct decision.

Also, the linking spec says the square brackets should not be escaped as they are now allowed in per RFC 2732.  Our spec escapes them.  This seems to be a bug and needs to be fixed.

Please provide guidance.

All the best, Ashok

-----Original Message-----
From: public-qt-comments-request@w3.org [mailto:public-qt-comments-request@w3.org] On Behalf Of C. M. Sperberg-McQueen
Sent: Friday, August 01, 2003 7:55 PM
To: public-qt-comments@w3.org
Cc: W3C XML Schema IG
Subject: XML Schema WG comments on Functions and Operators


Dear colleagues:

The XML Schema Working Group congratulates the XML Query and XSL
Working Groups on their progress, and in particular on the Last Call
draft of "XQuery 1.0 and XPath 2.0 Functions and Operators".

We have not been able to review the last call draft in as much detail
as we would have liked, but for what they are worth our comments are at
http://www.w3.org/XML/Group/2003/07/xmlschema-fo-comments.html (an
ASCII version is reproduced below for the convenience of those with
access to their email but not to the Web).

We apologize for the tardy arrival of these notes.

-C. M. Sperberg-McQueen, for the W3C XML Schema WG

................................................................


    [1]W3C [2]Architecture Domain [3]XML | [4]XML Schema | [5]Member
    Events | [6]Member-Confidential!

W3C XML Schema WG

Notes on XQuery 1.0 and XPath 2.0 Functions and Operators

1 August 2003
      _________________________________________________________________

      * 1. [7]Schema-related issues
           + 1.1. [8]Alignment of date/time values
           + 1.2. [9]The type anyAtomicType
           + 1.3. [10]The type untypedAtomic
           + 1.4. [11]Alignment on strings and URIs
           + 1.5. [12]Whitespace handling and lexical forms
           + 1.6. [13]Negative zero
           + 1.7. [14]Totally ordered Booleans
      * 2. [15]Other technical issues
           + 2.1. [16]The fn:base-uri property
           + 2.2. [17]Alignment of references
           + 2.3. [18]Characters and collation units
           + 2.4. [19]Surrogate pairs and Unicode scalar values
           + 2.5. [20]Definition of whitespace
           + 2.6. [21]Required normalization functionality
           + 2.7. [22]Case folding
           + 2.8. [23]Escaping URIs
           + 2.9. [24]The binary types
           + 2.10. [25]Minor items
                o 2.10.1. [26]User control of collations
                o 2.10.2. [27]Section 7.3.1.1 Examples
      * 3. [28]Editorial notes
      _________________________________________________________________

    This document contains comments on the Last Call draft of 2 May 2003
    of XQuery 1.0 and XPath 2.0 Functions and Operators transmitted to the
    XML Query and XSL Working Groups on behalf of the XML Schema Working
    Group. These draft comments have not been reviewed by the XML Schema
    Working Group and do not necessarily command consensus within the
    group; because we will not meet again until 28 August, the Working
    Group directed at its meeting today that these notes should be
    transmitted to the XML Query and XSL Working Groups without awaiting
    review.
    In addition to the comments below, please note that several of the
    [29]general comments sent on 14 July relate to the functions and
    operators and data model specifications. Some of those comments sent
    earlier overlap with some comments below.

1. Schema-related issues

    The comments in this section relate to the use of XML Schema in the
    F/O specification and thus to the particular area of responsibility
    borne by the XML Schema WG.

1.1. Alignment of date/time values

    The provision for preserving timezone information in the values of
    xs:dateTime, xs:date, and xs:time continues to concern us. We believe
    that a discrepancy of this kind between F/O and XML Schema will hurt
    users and impede uptake of both specifications.

    We believe F/O and XML Schema need to align on this, either by F/O
    changing to the XML Schema value space, or by changing the value space
    as part of XML Schema 1.1, or by some other mutually agreed upon
    solution.

1.2. The type anyAtomicType

    We reiterate our concern over the introduction of anyAtomicType into
    the type hierarchy. We believe that a discrepancy of this kind between
    F/O and XML Schema will hurt users and impede uptake of both
    specifications.

    We believe F/O and XML Schema need to align on this, either by F/O
    aligning with XML Schema 1.0 or by XML Schema 1.1 aligning with F/O.

1.3. The type untypedAtomic

    We reiterate our concern over the introduction of untypedAtomic into
    the type hierarchy. As with the other discrepancies, we believe
    alignment of the QT specs and XML Schema is critically important.
    Section 1.3.2 says xdt:untypedAtomic is used wherever the PSVI has
    xs:anySimpleType; please note that in the PSVI, this will be the case

      * when the element or attribute in question was declared as having
        type anySimpleType
      * when the attribute in question had no declaration and the schema
        processor assumed the simple urtype for it in the course of lax
        validation or error recovery

    Note that elements will not be assigned the anySimpleType as their
    type property in the course of lax validation or error recovery; they
    will have xs:anyType instead. Your use of xdt:untypedAtomic for
    xs:anySimpleType but not for elements which (a) lack child elements
    and (b) are assigned to xs:anyType may lead to results which puzzle
    some of your users; we believe you may wish to consider changing your
    mapping rules to assign xsd:untypedAtomic to such elements.

1.4. Alignment on strings and URIs

    The table at the beginning of section 2, Accessors, shows functions
    which are intended (judging by their names) to return URIs and which
    return values of type xs:string instead of xs:anyURI. Similarly,
    various functions which accept URIs as arguments are given signatures
    using xs:string as the type, which in turn necessitates ad hoc rules
    of the form "If $collationLiteral is not in the lexical space of
    xs:anyURI, an error is raised".

    As you know from our inquiry to you in mid-July, it has been suggested
    that in XML Schema 1.1 the xs:anyURI type be made a restriction of
    xs:string. But for now, there appears to be a discrepancy between the
    use of strings to represent URIs here and the provision of a distinct
    (and, for typing purposes, disjoint) type in XML Schema 1.0.
    We need to align on this.

1.5. Whitespace handling and lexical forms

    In section 5.1, paragraph 4 reads in part: "If the argument to a
    constructor function is a string literal, the literal must be a valid
    lexical form for its type ... Whitespace normalization is applied
    before validation ..."

    In all the cases which immediately come to mind, if the argument is a
    valid lexical form for a type, there is no need to perform any
    whitespace normalization on it. In XML Schema, it is the result of
    whitespace normalization, not the input to it, which must be a legal
    lexical form; we believe readers will be less confused if your usage
    of the terms and ours is consistent.

    A possible rewording: "If the argument to a constructor function is a
    string literal, then whitespace normalization is applied as indicated
    by the whitespace facet for the datatype. The whitespace-normalized
    string must be a valid lexical form for the type, as specified ..."

1.6. Negative zero

    In section 6, a note explains that the value space of xs:float and
    xs:double has been extended vis-à-vis that given by XML Schema, to
    include a negative zero. The note also explains that the negative zero
    will "never be obtained from the typed value of a node."

    We believe this discrepancy is untenable, and we are not clear why it
    has proven necessary to introduce it.

    As far as we can tell by examining the specification, the spec
    mentions different treatment for positive and negative zero only for
    the functions described in section 6.4 (fn:floor, fn:ceiling,
    fn:round, and fn:round-half-to-even): in the description of each of
    these functions it is noted that if a zero is given to the function as
    an argument, the sign of the zero returned as the value of the
    function is the same as the sign of the zero passed in as an argument.
    (The discussion of fn:ceiling mentions other cases when negative zero
    is returned; the discussion of fn:floor passes over the analogous
    cases in silence.) Other mentions of the signed zeroes in this
    specification invariably specify either that something is true both
    for positive and for negative zero or else that a constructor may
    return either a positive or a negative zero.

    Could you explain the motive for introducing this discrepancy with the
    value space defined in XML Schema? Would it not suffice to observe
    that IEEE 754 has both positive and negative zeroes, which are treated
    as different machine representations of the same values in the
    xs:float and xs:double value spaces, and (optionally) that the prose
    occasionally mentions these distinct representations of zero in the
    interests of alignment with IEEE 754, even though formally they are
    the same value?

    Is it essential to introduce an incompatibility with XML Schema here
    instead of treating positive and negative zeroes as one value with two
    machine representations?

1.7. Totally ordered Booleans

    We do not believe that it makes sense to impose a user-visible
    ordering on the Boolean data type. Can you explain the rationale?
    This is a discrepancy between F/O and XML Schema which must, we
    believe, be aligned.

2. Other technical issues

    The comments in this section relate to technical issues other than the
    use of XML Schema in the F/O specification; the XML Schema WG claims
    no particular responsibility or expertise on these questions but
    raises them because they seem to need attention.

2.1. The fn:base-uri property

    In section 2.5, the first paragraph defines a base-uri property for
    all node types: "Document, element and processing-instruction nodes
    have a base-uri property.... The base-uri of all other node types is
    the empty sequence."

    The next paragraph begins by explaining what happens "If the accessor
    is called on a node that does not have a base-uri property ..." If all
    nodes have the property, how can such a node exist?

2.2. Alignment of references

    XML Schema and the Functions and Operators spec should refer to the
    same version of Unicode. At the moment, this appears not to be true.

2.3. Characters and collation units

    The discussion of collation units in the second note of section 7.3
    says that collation decomposes a string "into a sequence of units,
    each unit consisting of one or more characters", and that various
    comparison operations are performed on these units. The functions
    fn:starts-with, fn:ends-with, fn:substring-before, and
    fn:substring-after are all mentioned as operating on such a segmented
    string.

    The list of functions at the beginning of section 7.4, however,
    describes them as operating on characters, not on the nameless
    collation units consisting of one or more characters each. This looks
    like a contradiction.

    We believe that the general level of confusion is best minimized, and
    the world becomes a better place, if in XML-related specifications the
    word character is used always and only for the units of the Universal
    Character Set defined by Unicode and by ISO 10646. The word should not
    be used (however great the temptation becomes at times) to denote the
    culturally specific units of writing systems (e.g. letters, symbols,
    signs, graphemes, or what have you).

    We suggest recasting the descriptions in 7.4 to describe the effect of
    the functions in terms of the collation units, rather than in terms of
    characters. In order to avoid repeating the phrase "the nameless units
    of one or more characters into which a collation segments a string for
    purposes of comparison", you may wish to define the term letter,
    grapheme, collation unit, or thingy with that meaning.

2.4. Surrogate pairs and Unicode scalar values

    Section 7.4.6 (like some others) has a note calling attention to the
    fact that some implementations will represent characters with code
    points higher than xFFFF by using surrogate pairs. You quite correctly
    avoid using the term code point for the things which make up the
    surrogate pair, since in section 7.1 you have defined code point as
    excluding surrogates. But the term 16-bit values is not defined, as
    far as we can tell.

    Also, in Unicode 2 and 3 there are (as far as we have been able to
    tell) no rules that forbid a double encoding of characters outside the
    Basic Multilingual Plane (i.e. first representing them within the BMP
    as surrogate pairs, and then encoding the sequence of BMP items in
    UTF-8). Even if it is discouraged (and it is indeed outlawed in
    Unicode 4.0), surrogate pairs might well show up not only in UTF-16
    but also in UTF-8, where they will presumably be presented by
    Unicode-oblivious character libraries not as pairs of 16-bit values
    but as four-octet sequences whose intepretation in terms of Unicode
    scalar values requires slightly special rules.

    Note that the definition of code points given in section 7.1 agrees
    with the definition of Unicode scalar values in Unicode 4.0 in
    excluding the surrogate range, but not with Unicode 2.0 (the version
    cited in your normative references), or Unicode 3, which define a
    Unicode scalar value as "a number N from 0 to 10FFF[16]", without
    leaving any gap for the surrogates.

2.5. Definition of whitespace

    Section 7.4.10 defines the function fn:normalize-space as doing
    various things to whitespace, but it does not define the term
    whitespace. It should, since various definitions are possible.
    The Unicode character database, for example, lists the following
    Unicode characters as whitespace in the file PropList-3_1_0.txt:

      * 0009..000D ; White_space # Cc [5] <control>..<control>
      * 0020 ; White_space # Zs SPACE
      * 0085 ; White_space # Cc <control>
      * 00A0 ; White_space # Zs NO-BREAK SPACE
      * 1680 ; White_space # Zs OGHAM SPACE MARK
      * 2000..200A ; White_space # Zs [11] EN QUAD..HAIR SPACE
      * 2028 ; White_space # Zl LINE SEPARATOR
      * 2029 ; White_space # Zp PARAGRAPH SEPARATOR
      * 202F ; White_space # Zs NARROW NO-BREAK SPACE
      * 3000 ; White_space # Zs IDEOGRAPHIC SPACE

    The XML specification defines a smaller set of characters as
    whitespace, for purposes of whitespace normalization.

    So some definition is definitely needed.

2.6. Required normalization functionality

    Section 7.4.11 requires conforming implementations to support Unicode
    normalization form NFC.

    Why is normalization form W3C not also required?

2.7. Case folding

    Sections 7.4.12 and 7.4.13 define functions for case folding.
    Since case folding is not consistent across languages and locales, we
    have grave doubts about the wisdom of this inclusion, and some members
    of the WG would advise you to drop these functions, which are not and
    cannot be language- and culture-neutral.

    There is precedent: the decision to drop case-folding of names from
    the design of XML resulted from the realization that every
    case-folding algorithm available, including the use of the Unicode
    case mapping tables, has an inherent cultural bias. The inclusion of
    culturally and linguistically biased functions does not contribute to
    achieving the goal of universal accessibility for the Web. Some
    members of the XML Schema WG believe your spec should not go forward
    with these functions in it.

    If you retain these functions, you should at the very least warn users
    that

      * Results may violate user expectations (in Québec, for example, the
        standard uppercase equivalent of "é" is "É", while in metropolitan
        France it is more commonly "E"; only one of these is supported by
        the function as defined).
      * Many characters of class Ll lack uppercase equivalents in the
        Unicode case mapping tables (we stopped counting at 150 or so);
        many characters of class Lu lack lowercase equivalents.
      * The two functions are not inverses of each other, so that for a
        string S of upper-case characters, fn:upper-case(fn:lower-case(S))
        is not guaranteed to return S, nor is
        fn:lower-case(fn:upper-case(S)) for a string S of lower-case
        characters. Latin small letter dotless i (as used in Turkish) is
        perhaps the most prominent lower-case letter which will not
        round-trip, as Latin capital letter i with dot above is the most
        prominent upper-case letter which will not round trip; there are
        others.

    You may also wish to make the case mapping depend on the default or a
    user-specified collation.

2.8. Escaping URIs

    The rules for escaping URIs should be aligned across all W3C
    specifications; otherwise, we will drive our users crazy.

    We think that means that you should reference and implement the
    algorithm specified in the XML Linking specification
    ([30]http://www.w3.org/TR/2001/REC-xlink-20010627/#link-locators) and
    referenced by XML Schema, or the algorithm given in the W3C Character
    Model specification (which was the same algorithm the last time we
    looked).

    In particular, some members of the XML Schema WG were surprised to see
    that your algorithm escapes the percent sign in some cases but not
    others; this does not seem to be a feature of the algorithm given by
    XML Linking and by the Character Model.

    That said, we believe that you do your readers a good service by
    listing explicitly the affected characters. By suggesting that you
    refer to the Linking/CharMod algorithm, we do not mean to suggest that
    you should make your spec less useful by omitting these lists.
    (Editorial note: it would perhaps be useful to some readers to have a
    brief discussion of why the advice given in the last paragraph should
    be followed; our readers did not understand the rationale for this
    advice.)

2.9. The binary types

    Section 12.1.1 says that op:hexBinary-equal returns true if its
    arguments "are of the same length and contain the same code-points";
    similarly in 12.1.2 for op:base64Binary-equal.

    The term code-point was defined in section 7.1 as denoting integers
    between 0 and 1114111 (x10FFFF), with a gap in the range where Unicode
    surrogates occur. It seems to be used here to denote what other
    specifications refer to as octets (bit strings of length 8).

    Taking the term code point in the sense of `octet', the definition
    still does not match our intuitions of what an equality test on binary
    data must do: it is not enough that each argument contain the same
    octets; they must contain them in the same order.

    Suggested rewording: "are identical strings of octets". If you wish to
    avoid the word octet, "are identical bit strings" might do, although
    it omits the relatively important fact that the values in question
    must have 8×n bits for some integer n.

2.10. Minor items

2.10.1. User control of collations

    Section 7.3 says in part "This specification does not use xml:lang to
    identify the default collation, in part because collations should be
    determined by the user of the data, not (normally) the data itself,
    and because ..."

    The second reason given is sound. The first (collations should not
    normally be determined by the data) is often advanced as a principle,
    but does not seem to all members of the XML Schema WG to be
    universally true. We are thus grateful for the "(normally)" in the
    sentence. But in any case, the first reason given here leads to a
    non-sequitur: it would be a reason not to make xml:lang determine the
    collation sequence without possibility of user override. But it does
    not, even on its face, provide a reason not to use xml:lang to
    identify the default collation. We suggest dropping the first reason;
    the second suffices.

2.10.2. Section 7.3.1.1 Examples

    The fourth example in section 7.3.1.1 says that

       fn:compare('Strassen', 'Straße')

    "returns 1 if and only if the default collation includes provisions
    that equate `ss' and the (German) character `ß' (`sharp-s')." Unless
    we have misunderstood the definition of the function, the return value
    should also be 1 if the default collation sorts "ß" (sharp s) before
    "s". Deleting the phrase "and only if" would remove the error.

3. Editorial notes

    In the course of our work, some editorial points were noted; we list
    them here for the use of the editors. We do not particularly expect
    formal responses on these comments.

     1. Definition of must. Section 1.1 defines must thus:

          Conforming documents and processors are required to behave as
          described; otherwise, they are non-conformant or in error.

        Is the "or" inclusive or exclusive, or is "in error" intended as a
        synonym or approximate synonym for "non-conformant"? Possible
        alternatives: "otherwise, they are non-conformant and in error",
        "otherwise, they are either non-conformant or else in error",
        "otherwise, they are non-conformant, i.e. in error".

     2. Definition of stable. In section 1.1, the definition of stable
        says, inter alia:"Some other functions ... have an explicit
        dependency on the dynamic context". Unless this means that they
        accept an argument representing the dynamic context, it seems at
        first glance as if explicit is here used with the meaning
        `implicit'. Perhaps what is intended is that the documentation
        will explicitly mention this dependency. Perhaps the best thing to
        do would be just to drop the explicit; if you really wish to
        stress the promise of documentation, perhaps read "Some other
        functions ...have a depencency on the dynamic context ... These
        functions are said to be contextual. [INS: Contextual functions
        are always identified as such in their descriptions. :INS] "

     3. The term back up. The phrase back up appears to be used several
        times as a technical term (e.g. last paragraph of 1.7). What does
        it mean?

     4. The term QName. Some readers (including some members of the XML
        Schema WG) are likely to find it disorienting for the term QName
        to be used here as a synonym for expanded name or universal name,
        and not with the same meaning QName has in the XML Namespaces
        Recommendation. We recognize, however, that what is returned is
        precisely a member of what XML Schema 1.0 defines as the value
        space of the xs:QName type, so that the use of the term xs:QName
        to denote (for example) the return type of the accessor
        fn:node-name is not only unexceptionable but necessary for
        consistency. We don't have a good solution for you here; we only
        note the difficulty. Perhaps a note calling the reader's attention
        to the issue would be in order (similar to the note on this topic
        in the Data Model spec).

        Some members of the WG suggest that this spec, like the Data
        Model, should prefer the term expanded QName where possible, to
        stress that what is referred to is the pair in the value space,
        not the colonized Name in the lexical space.

     5. No parameters and the empty list of parameters:

        On first reading, the signatures of fn:string and fn:error suggest
        an ambiguity to some readers: the call fn:error() appears to match
        both the first and the second signatures.

        Members of the WG who have studied XQuery more thoroughly assure
        the rest of us that there is no ambiguity, so our purpose in
        making this comment is merely to call your attention to an
        editorial problem: it might be useful to explain to the reader why
        the dual signatures showing no arguments and optional arguments
        are not in fact ambiguous.

     6. Section 2.3, first note: the word this seems to need an
        antecedent; it is not clear to this reader, at least, what that
        antecedent is. (It's also not clear what problem with blanks in
        fragment identifiers is being adverted to.)

     7. Raising errors: Section 3 para 1 reads in part: "The occurrence of
        that phrase [sc. `an error is raised'] implicitly causes the
        invocation of the fn:error function ..." This formulation seems to
        involve a horrible clash of contexts: the phrase "an error is
        raised" occurs in this document, and it occurs continuously from
        the time of publication until the document ceases to exist (if
        documents can ever cease to exist), while the error, one expects,
        ought to be raised in a software system which implements the spec,
        and should probably not be raised continuously from now until the
        spec ceases to exist, if only because it would make it hard for
        users to get work done. For the occurrence of a phrase in the spec
        to cause the raising of an error in conforming software seems to
        involve a rather unusual kind of action at a distance. To speak a
        bit more seriously: perhaps the relevant part of the paragraph
        could be recast, perhaps along these lines: "the phrase `an error
        is raised' is used to describe the behavior of conforming
        processors in certain situations. When such situations arise in a
        running system, a conforming implementation of this specification
        must invoke the fn:error function defined in this section." This
        is not perfect, but we hope you get the idea.

     8. Type promotion in multiple or single steps: Section 6.2 says "As
        far as possible, the promotions should be done in a single step.
        Specifically, when a decimal is promoted to a double, it must not
        be converted to a float and then to a double, as this risks loss
        of precision." [Emphasis added.] These two sentences appear to
        contradict each other: is the rule about single-step conversions
        required of conforming implementations ("must"), or recommended
        without being required ("should")?

     9. Code points: The note in section 7.1 identifies code points as
        Unicode scalar values (which are in turn integers), but uses the
        notation #x0000 and #x10FFFF to refer to the minimum and maximum
        values. It's not terribly confusing in context, but strictly
        speaking, this notation is defined in the XML specification as
        denoting characters, not integers. I believe conventional
        representations for hexadecimal numbers would write these values
        as 0, 0H, x0, or 0x, and correspondingly 10FFFFH, x10FFFF, or
        10FFFFx; there may be other hexadecimal representations you will
        prefer. The Unicode specification writes 10FFFF[16].

    10. v and w: Section 7.3 says "`uve' and `uwe' are considered
        equivalent in some European languages"; this is unexpected. Are
        you sure? Which languages?

    11. Section 7.4 para 1: for "function" read "functions". Here and
        elsewhere, we believe that sentences like "Several of these
        functions use a collation" would do better if "a collation" were
        replaced with a plural: "Several of these functions use a
        collation." Unless, of course, all of these functions always use
        the same collation.

    12. Section 7.4.6.1, final example: forgive this observation if it's
        clueless, but since there does not seem to be any addition
        operator in the example (did we miss it?), it's not immediately
        obvious what -INF + INF has to do with the interpretation of the
        example.

    13. Section 7.4.15, fn:string-pad: this seems an unfortunate choice of
        names for a function which does not (despite its name) pad a
        string with blanks or some other padding character(s), but which
        simply replicates or copies the string multiple times. Could it be
        renamed without excessive heartburn?

    14. Section 7.4.16, fn:escape-uri: It would help minimize confusion if
        the lists of characters which are or are not escaped gave the
        character names as well as the characters themselves in quotation
        marks. (In the paper copy used by one member of our review task
        force, this bit of the spec was almost impossible to make out
        without a magnifying glass.)

    15. Section 7.5.3, fn:replace: The description of the function seemed
        unclear:

            The function returns the xs:string that is obtained by
            replacing all non-overlapping substrings of $input that
            match the given $pattern with an occurrence of the
            $replacement string.

        Replacing all occurrences of the pattern with an occurrence of the
        replacement string seems to suggest an n for 1 exchange. For "all"
        read "each". In the following paragraph, one occurrence of $input
        is not marked as an identifier, one is.


References

    1. http://www.w3.org/
    2. http://www.w3.org/Architecture/
    3. http://www.w3.org/XML/Group
    4. http://www.w3.org/XML/Group/Schemas
    5. http://www.w3.org/Member/Eventscal.html
    6. http://www.w3.org/Member/#confidential
    7. http://www.w3.org/XML/Group/2003/07/xmlschema-fo-comments.html#d0e65
    8. http://www.w3.org/XML/Group/2003/07/xmlschema-fo-comments.html#d0e70
    9. http://www.w3.org/XML/Group/2003/07/xmlschema-fo-comments.html#d0e86
   10. http://www.w3.org/XML/Group/2003/07/xmlschema-fo-comments.html#d0e98
   11. http://www.w3.org/XML/Group/2003/07/xmlschema-fo-comments.html#d0e145
   12. http://www.w3.org/XML/Group/2003/07/xmlschema-fo-comments.html#d0e178
   13. http://www.w3.org/XML/Group/2003/07/xmlschema-fo-comments.html#d0e191
   14. http://www.w3.org/XML/Group/2003/07/xmlschema-fo-comments.html#d0e238
   15. http://www.w3.org/XML/Group/2003/07/xmlschema-fo-comments.html#d0e246
   16. http://www.w3.org/XML/Group/2003/07/xmlschema-fo-comments.html#d0e251
   17. http://www.w3.org/XML/Group/2003/07/xmlschema-fo-comments.html#d0e278
   18. http://www.w3.org/XML/Group/2003/07/xmlschema-fo-comments.html#d0e283
   19. http://www.w3.org/XML/Group/2003/07/xmlschema-fo-comments.html#d0e327
   20. http://www.w3.org/XML/Group/2003/07/xmlschema-fo-comments.html#d0e350
   21. http://www.w3.org/XML/Group/2003/07/xmlschema-fo-comments.html#d0e392
   22. http://www.w3.org/XML/Group/2003/07/xmlschema-fo-comments.html#d0e399
   23. http://www.w3.org/XML/Group/2003/07/xmlschema-fo-comments.html#d0e444
   24. http://www.w3.org/XML/Group/2003/07/xmlschema-fo-comments.html#d0e463
   25. http://www.w3.org/XML/Group/2003/07/xmlschema-fo-comments.html#d0e513
   26. http://www.w3.org/XML/Group/2003/07/xmlschema-fo-comments.html#d0e516
   27. http://www.w3.org/XML/Group/2003/07/xmlschema-fo-comments.html#d0e544
   28. http://www.w3.org/XML/Group/2003/07/xmlschema-fo-comments.html#d0e577
   29. http://www.w3.org/XML/Group/2003/07/xmlschema-query-notes.html
   30. http://www.w3.org/TR/2001/REC-xlink-20010627/#link-locators
Received on Monday, 10 November 2003 09:05:09 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Tuesday, 27 March 2012 18:14:28 GMT