W3C home > Mailing lists > Public > public-qt-comments@w3.org > May 2005

[Bug 1284] New: use of xsl:type in XqueryX instances

From: <bugzilla@wiggum.w3.org>
Date: Tue, 03 May 2005 09:39:48 +0000
To: public-qt-comments@w3.org
Cc:
Message-Id: <E1DStsa-0006tn-QF@wiggum.w3.org>

http://www.w3.org/Bugs/Public/show_bug.cgi?id=1284

           Summary: use of xsl:type in XqueryX instances
           Product: XPath / XQuery / XSLT
           Version: Last Call drafts
          Platform: PC
        OS/Version: Windows 2000
            Status: NEW
          Severity: normal
          Priority: P2
         Component: XQueryX
        AssignedTo: jim.melton@acm.org
        ReportedBy: davidc@nag.co.uk
         QAContact: public-qt-comments@w3.org


XqueryX currently uses a mixture of specific elements
eg <xqx:forExpr> and generic elements modified via xsi:type
eg    <xqx:expr xsi:type="xqx:flworExpr">

It would be a lot more consistent (and a lot less ugly) if the
need for xsi:type was removed and specific elements were added to cover all
cases, so for example <xqx:flworExpr>

XqueryX isn't intended for human consumption so perhaps uglyness will not be
seen as a valid argument, so perhaps a more important reason is that using the
Qname in an attribute value here makes it much harder to generate or process
xqueryx with generic XML tools.

Currently xqueryx is normatively defined via an xslt1 stylesheet that tests for

  <xsl:template match="xqx:expr[@xsi:type='xqx:flworExpr']">

This means that any tool generatng XqueryX _must_ use the xqx prefix here.
Just being valid to the XSD schema is not enough.

This is rather hard to arrange if the xqueryx document is being written using
some generic xml-namespace/xml-schema processing pipeline which might have its
own ideas about which prefixes to use for which namespaces.

Conversely if the normative definition were changed from the current xslt1
string comparison to (say) an xslt2 schema-aware comparision of a Qname type
attribute value then the prefixes could be arbitrary but it would be much harder
to process XqueryX with an installed base of schema-unaware tools such as xslt1
or XSLT2-basic (or Xquery without schema support).

If instead, you simply had to do a namespace aware comparision of element names,
then pretty much any current XML processing application could handle xqueryx files.


David
Received on Tuesday, 3 May 2005 09:39:54 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 16:57:05 UTC