XSL WG Comments on XML Query Requirements Document

General

There is significant overlap in the required functionality expressed by the Goals and Usage Scenarios of the XML Query Requirements on the one hand, and XSLT functionality (whether existing or planned) on the other.

We see two kinds of overlap:

Requirements that are compatible with XSLT 1.0 functionality, either existing or planned.
Requirements that call for coordination or compatibility with other W3C specifications (such as XML Infoset and XML Schema) and for new functionality (such as working with collections) that XSLT must also accomplish.

The XSL WG sees these overlaps as opportunities for joint work between the two working groups, so as to avoid the emergence of multiple methods for accomplishing the same results.

In general, regarding the stated goal of the Query WG to produce a data model for XML documents, the XSL WG considers that it would be appropriate to use and extend, where necessary, XPath/XSLT's data model rather than specify a completely new data model. It should also be noted that XPath/XSLT's data model will be extended to account for XML Schema data types in XSLT 2.0. In the context of the W3C, coordination and collaboration in this area between the XSL WG and the XML Query WG seems to be a must.

Because the data model for collections will impact more than just the XML Query WG, the XSL WG believes that there should be a separate specification dealing with operations on collections, separate from, but subordinate to, the XML Query Language rather than as an intrinsic part thereof -- just as the XPath specification was separate from but subordinate to XSLT.

As regards support for NULL values, the XSL WG would like to collaborate with the Query WG on extending XPath and XSLT, so that when this requirement is met by the XML Query Language, both XPath and XSLT do too.

As an aside, the XSL WG notes that it would be useful to include a section in the XML Query Requirements Document specifying those things that XSLT cannot currently accomplish which XML Query is designed to accomplish. Such a section would reduce some of the confusion caused by the observed overlap.

Requirements that are compatible with XSLT functionality

The following table lists specific requirements that the XSL WG believe are partially or fully compatible with XSLT 1.0 functionality, or that are already planned for version 2.0 of XSLT and would benefit from collaboration between the two groups.

Requirements Doc	Description	XSLT comments
1, 2.1, 2.2, 3.4	Select whole documents or subtrees, construct new documents, generate table of contents, search for information in structures found within a document, generate new documents, transform data into new XML representations	Performs currently.
2.1-2.5	Various XML data manipulation user scenarios	Operates on any XML data
2.6, 4 (DOM)	DOM interaction	Is compatible with DOM 1.0; many XSLT processors read and write DOM instances
3.2.1	XML syntax	Is expressed in XML
3.2.2	Declarative	Is declarative
3.2.4	Error conditions	Defines its error conditions
3.2.5	Updatable	Does not preclude additional capabilities in later versions, has well defined mechanism for versioning.
3.2.6	Finite instances	Is defined for finite instances
3.3.11	Data model compatible with Infoset	Planned for version 2.0
3.3.2	Character data	Can represent XML 1.0 character data
3.3.2	Represent data types defined by XML Schema.	Planned for version 2.0
3.3.5	Operate on XML data whether or not there is a schema, and represent any items defined in the schema instance, if present	Planned for version 2.0
3.3.6	Namespace aware	Is namespace aware
3.4.3	Universal and existential quantifiers	Has support for universal quantifiers and some support for existential quantifiers. More support is planned for version 2.0
3.4.4	Hierarchy and Sequence	Supports operations on document structures
3.4.5	Combination	Can combine information from different parts of a given document or from multiple documents
3.4.6	Aggregation	Planned for version 2.0
3.4.7	Composition	Can compose operations
3.4.9	Preservation	Can preserve the relative hierarchy and sequence of input document structures in transformed results
3.4.10	Transformation	Can transform XML structures and create new structures
3.4.13	Literal data	Can operate on literal data
3.4.14	Name operations	Can operate on names, including element and attributes names and PI targets
3.4.16	Extensibility	Has an extensibility mechanism
3.4.17	Environment	Has a function for getting environment data
3.4.18	Closure	Is closed with respect to its data model

Requirements that call for collaboration or cooperation

The following table summarizes the list of requirements that the XSL WG as identified as opportunities for collaboration, coordination or joint effort:

Requirement	Description
1, 3.3	Data model
3.3.1	Infoset
3.3.2, 3.4.15	Schema
3.3.3	Collections
3.4.3	Quantifiers
3.4.8	NULL values
3.4.16	Extensibility

Comments by Section

Section 2 Usage Scenarios

Section 2.2:

The XSL WG would like to see a clarification regarding querying databases: where will the XML Query WG set the boundary between the XML representation of the data and the database representation of the data. Will a specification for directly querying databases be developed?

Section 2.3:

Since XML intrinsically handles both data and documents, the reason for the distinction here needs to be clarified. Would it be better served by clarifying the boundary line between the XML representation of the data and the database representation of the data as it relates to the query languge?

Section 2.4

Are these types of XML data being singled out because the XML Query language will have special support for these cases?

Section 2.6

The XSL WG wonders whether the DOM might be too low a level for this, and whether the Infoset would be a better interface. However, if the Query WG decides to leave this as is, a clear indication of what DOM version is being talked about is needed.

Section 3.2 General Requirements

There does not appear to be a use case justification for requiring that XML Query have an XML syntax. Perhaps some clarification is necessary here to explain the rationale.

The XSL WG recognizes that a non-XML syntax is necessary for easily encoding XML Query expressions in URLs. If an XML syntax representation is indeed necessary, perhaps a subset of XML Query could be a string-based syntax.

The XSL WG strongly believes that the Query WG would be doing a significant contribution to the web environment by inventing a URI scheme for XML Query operations by extending XPath in some way.

Section 3.2.2

The XSL WG believes that XSLT and XPath are declarative, particularly for select patterns, since no ordering of expression evaluation is mandated.

Section 3.2.4

Is the lack of a mention of a fall-back strategy intentional?

Section 3.2.6

The XSL WG feels this needs to be clarified. What is "infinite" -- is this meant literally? If so, how can an infinite XML data be transformed?

It is not clear what the impact of this requirement will be on the design of the language, data model and processing model. It also seems contradictory to the requirement for closure, 3.4.18.

Section 3.3 XML Query Data Model

Section 3.3.1

The XSL WG has a similar task, and believes the efforts of both WGs should be coordinated.

Section 3.3.2

There is overlap between the XML Query requirements and the XSLT version 2 requirements. XSLT version 2 must also represent data types defined by XML Schema. Coordination between the two WGs is desirable; this is an opportunity for joint work.

Section 3.3.3

In section 3.3.3 "collections of simple and complex values" needs to be clarified. Is "collections of instances of simple and complex types" what is meant?

The XSL WG thinks that this requirements document should additionally list the requirements for collections, or there should be a separate requirements document for collections.

The XSL specifications also need to handle collections, and we see this as an opportunity for joint work. In addition, the XSL WG thinks that collections have a broader scope of usefulness within the W3C and should not be integral to the XML Query language but rather separate from and subordinate to it.

Section 3.3.4

The XSL WG would like some clarificaton on what functionality is being talked about.

Section 3.3.5

What does a schema being "available" mean? Is there a difference between "available" and "present"? In addition, does this section imply that the data model "must represent" schema items, or that the data model "must be able to" represent schema items?

Section 3.4 XML Query Functionality

Most sections of section 3.4 seem to have significant overlap with XSLT functionality (in some instances with XSLT 2.0 requirements). See the table above.

Section 3.4.2:

How will text that spans element boundaries be represented in the data model? What sort of operations are required? Is this functionality similar to ranges in XPointer?

Section 3.4.3:

XSLT has some support for the functionality required, and XSLT 2.0 has the requirement to extend this functionality. We see this as an opportunity for collaboration.

Section 3.4.4

Does "sequence" mean "document order"?

Section 3.4.5

What kind of relationships does the Query WG plan to support? This needs clarification, perhaps some examples.

Section 3.4.6

What kinds of aggregation will be supported? Some examples would be helpful.

Section 3.4.8

The XSL WG would like to collaborate on extending XPath and XSLT so that when this requirement is met by the XML Query Language, XPath and XSLT will support it too.

Section 3.4.10

It isn't clear whether the transformed structures contain copies of or references to the original XML nodes.

Does "an XML structure" mean a subtree (i.e. rooted subtree), or is it more like an XSLT result fragment? This needs clarification.

Section 3.4.11

It is not clear what functionality is being required here. Examples as well as clarification would be helpful.

Section 3.4.12

In the context of constructing a result set, it is not clear what this requirement means.

Section 3.4.13

This needs to be clarified. What does "literal data" mean?

Section 3.4.14

What operations are to be performed, and what kinds of combinations of names and data are to be supported?

Section 3.4.15

There is a similar requirement for XSLT 2.0 (though only support for Schemas, not DTD's). We see this as an opportunity for joint work.

Section 3.4.16

XSLT has an extension mechanism but no language bindings. The XSL WG is planning to further define the mechanisms for extension functions as part of XSLT 2.0 (or perhaps in a separate specification). Coordination or joint work is desirable.

Section 4 Relationship to Other Activities

"DOM" It is not clear what the impact of this requirement will be on the design of the language, data model and processing model. Additionally, a clear indication is needed of what DOM version is being talked about.

"XSL, XPointer" should be separated into XSL, XPath, and XPointer. XPointer is defined by a working group separate from the XSL WG. XPath is a Recommendation used by both XSLT and XPointer.

The "XSL, XPointer" paragraph seems to imply that the XML Query group will try to duplicate the functionality of XPath when formulating its language, but is not committed to using it, i.e. it reserves the possibility of creating its own language. The XSL WG urges that both XPath and XSLT be used as the syntactic basis for the XML Query Language, not merely as its functional basis.