This is an archived snapshot of W3C's public bugzilla bug tracker, decommissioned in April 2019. Please see the home page for more details.

Bug 1284 - use of xsl:type in XqueryX instances
Summary: use of xsl:type in XqueryX instances
Status: CLOSED FIXED
Alias: None
Product: XPath / XQuery / XSLT
Classification: Unclassified
Component: XQueryX 1.0 (show other bugs)
Version: Last Call drafts
Hardware: PC Windows 2000
: P2 normal
Target Milestone: ---
Assignee: Jim Melton
QA Contact: Mailing list for public feedback on specs from XSL and XML Query WGs
URL:
Whiteboard:
Keywords:
Depends on:
Blocks: 1285
  Show dependency treegraph
 
Reported: 2005-05-03 09:39 UTC by David Carlisle
Modified: 2005-08-08 23:14 UTC (History)
0 users

See Also:


Attachments

Description David Carlisle 2005-05-03 09:39:48 UTC
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
Comment 1 Jim Melton 2005-06-02 20:31:44 UTC
The XML Query Working Group has discussed this comment at some length and is
sympathetic to making the sort of changes that you have suggested.  A further
comment will be added to this bug report when the actual changes have been
worked out. 
Comment 2 Ashok Malhotra 2005-06-26 23:30:45 UTC
The Query WG agrees with your suggestion and has revised the XQueryX schema to
eliminate the use of the <xqx:expr> element in XQueryX instance documents (in
the schema, it remains as an abstract element).  Those changes are still subject
to review and change by the WG.  When they are approved, another comment will be
added to this thread.  When, and if, the changes become visible to you, we hope
that you will review them and mark this comment CLOSED.