your comments "NM-XQ-6: xs:anyUri and xs:string" and "URIs and strings (XML Schema comment on F/O)"

Summary 

This note is to reply to two different comments on the treatment
of xsd:anyURI in the Last-Call drafts.  Both the XML Schema WG
and Noe Michejda have objected that the last call drafts make the
type less useful because it is not coerced to string when needed.

The XML Query and XSL Working Groups have considered these issues
and agreed to add type promotion rules to ensure that anyURI
values may be used where values of type string are expected.


Details of the comments

XML Schema WG, Notes on XQuery 1.0 and XPath 2.0 Functions and
Operators 1 August 2003, section 1.4 Alignment on strings and URIs
http://www.w3.org/XML/Group/2003/07/xmlschema-fo-comments.html#d0e145

    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.

XML Schema WG to public issues list 27 February 2004:
http://lists.w3.org/Archives/Public/public-qt-comments/2004Feb/1230.html

    This note is to ensure that your last-call issues list
    includes a question we raised already in our earlier review
    of the Functions and Operators specification; in our notes on
    that spec of last 1 August, it had item number 1.4 [1].  (I
    took an action to write you on this account some time ago.
    My apologies for the delay, but I venture to hope that our
    concern will not come as a surprise to you.)

    While we understand (even if we do not fully agree with) the
    reasoning which has led you to make all of the functions for
    operations upon URIs accept strings as arguments, we have not
    understood the reasoning which leads you to require that they
    raise an error if they are given an argument of type anyURI,
    and we respectfully suggest that you ensure that these
    functions can be called upon arguments of type anyURI without
    raising a type error, and that the results can where
    appropriate conveniently be coerced into type anyURI.

    The status quo would have the effect of discouraging the use
    of the anyURI type and of encouraging users to lie to their
    processors by typing values as strings instead of typing
    them, more accurately and more usefully, as URIs.

Noe Michejda, 7th Portal S.C., to comments list 24 February 2004
http://lists.w3.org/Archives/Public/public-qt-comments/2004Feb/1142.html

    Build-in type xs:anyUri deserves better treatment in my
    opinion.

    Currently it can be only compared with another xs:anyUri or
    casted to string.  But basically it is a string with
    additional restriction on structure (like pattern facet).  So
    xs:anyUri should be treated as derivation by restriction from
    xs:string by all XPath/XQuery rules.

    This will allow to define function signatures using xs:anyUri
    and remove lexical checks from definitions of functions.

    Maybe it will be possible to change derivation diagram in XML
    Schema 1.1 and reference it instead of 1.0 in XPath 2.0 /
    XQuery 1.0 ? This will be simpliest solution.  (and btw allow
    placing dayTimeDuration and yearMonthDuration in schema
    namespace)


Details of the decision

The XML Schema Working Group considered, but decided against,
making anyURI a subtype of string in XML Schema 1.1: there are
special semantics associated with anyURI which cannot be captured
by derivation, so it seemed to the WG advisable to retain it as a
primitive type.

Instead, specific type promotion rules will be added to handle
the promotion of anyURI to string when needed.

Section 3.1.5 of XQuery will be revised to add a type promotion
rule specifying that

    4. For each item of type xs:anyURI in the atomic sequence
    that can be promoted to the expected atomic type using the
    URI promotion rules in B.1.2 URI Type Promotion, the
    promotion is done.

Appendix B.1 of XQuery will be revised to say, in part: 

    B.1.2 URI Type Promotion 

    1. A value of type xs:anyURI (or any type derived by
    restriction from xs:anyURI) can be promoted to the type
    xs:string (or any type derived by restriction from xs:string)
    by casting the original value to the target type of the
    promotion.

Appendix B.2 of XQuery will be revised to say, in part:

    Under certain conditions, operands of certain types need to
    be promoted to the other operand's type using the type
    promotion rules. In case one of the operand is an instance of
    type xs:anyURI and the other operand is an instance of type
    xs:string, the operand of type xs:anyURI (or any derived type
    thereof) is promoted to xs:string before applying the
    remainder of the operator mapping. The numeric type promotion
    is described below.

    NOTE: This makes eq of values that involve xs:anyURI and
    xs:string non-transitive...


Analogous changes will be made where necessary to other
documents; since the Functions and Operators specification does
not specify the type promotion rules independently, no impact is
likely to be visible there.

Please let us know whether this addresses your concerns
adequately.  Thank you for your interest in our specifications.

On behalf of the XSL and XML Query Working Groups,

Michael Sperberg-McQueen

Received on Sunday, 22 August 2004 19:03:47 UTC