Response to XSL WG comments

The XML Query Working Group thanks the XSL Working Group
for the comments
(http://lists.w3.org/Archives/Member/w3c-xml-query-wg/2000May/att-0175/01-fi
nal-_xsl_comments_on_query.htm)
on the first public working draft of the XML Query Requirements
document (version January, 31 2000). We have extracted 26 individual
comments from the XSL WG comment document and agreed on the
following responses.  We look forward to the opportunity to discuss these
responses at our future F2F joint meeting.

(<comment> marks up XSLT WG comments,
<requirements> marks up the corresponding requirement in the
XML Query Requirements document).

XSL-Comment-001: Querying Databases via XML
--------------------------------------------

In Section "Comments by Section" the XSL-WG writes:
<comment>
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?
</comment>

<requirements>
2.2 Data-oriented documents 

Perform queries on the XML representation of database data, object data, or
other traditional data sources to extract data from these sources, to
transform data into new XML representations, or to integrate data from
multiple heterogeneous data sources. The XML representation of data sources
may be either physical or virtual; that is, data may be physically encoded
in XML, or an XML representation of the data may be produced.
</requirements>

XML Query WG Response: This distinction has just been introduced for
illustration purposes. XML Query 1.0 does not plan to develop a
specification to directly querying databases; neither does XML Query
plan to define a normative mapping between databases and XML. For
the formal semantics of an XML Query the distinction between
physical or virtual documents is immaterial.

XSL-Comment-002: Distinction between Data and Documents
--------------------------------------------------------

In Section "Comments by Section" the XSL-WG writes:
<comment>
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?
</comment>

<requirements>
2.3 Mixed-model documents 

Perform both document-oriented and data-oriented queries on documents with
embedded data, such as catalogs, patient health records, employment
records, or business analysis documents.
</requirements>

XML Query WG Response: We agree that this requires clarification. Usage
Scenario 2.3 just emphasizes the need for combining data-oriented
queries (see also Usage Scenario 2.2) with document-oriented queries
(see also Usage Scenario 2.1). The usage scenario does not imply any
boundary line in the representation of data and documents. For
clarification the next version of the requirements will be changed as
follows:
(a) Heading of Section 2.1 -> "Document-Oriented Queries"
(b) Heading of Section 2.2 -> "Data-Oriented Queries"
(c) Heading of Section 2.3 -> "Mixed Model Queries"
(d) Text of Section 2.3: "Perform a combination of
document-oriented and data-oriented queries on documents with
embedded data, such as catalogs, patient health records, employment
records, or business analysis documents."

XSL-Comment-003: Querying administrative data
----------------------------------------------

In Section "Comments by Section" the XSL-WG writes:
<comment>
Section 2.4

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

<requirements>
2.4 Administrative data 

Perform queries on configuration files, user profiles, or administrative
logs represented in XML.
</requirements>

XML Query WG Response: This usage scenario is only for illustrative
purposes. No special support is planned for such data. However, some
of the functional requirements such as "3.4.17 Access to Environment
Information" have been motivated (among others) by such usage
scenarios.

XSL-Comment-004: Relationship to DOM
-------------------------------------

In Section "Comments by Section" the XSL-WG writes:
<comment>
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.
</comment>

<requirements>
2.6 Document Object Model (DOM) 

Perform queries on DOM structures to return sets of nodes that meet the
specified criteria.
</requirements>

and

<comment>
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.
</comment>

<requirements>
DOM 

The XML Query Language must be able to return results in a form that can be
used in DOM programs, such as DOM Nodes or the Iterators and TreeWalkers
defined in the Traversal specification (W3C members only).
</requirements>

XML Query WG response: Returning DOM-nodes provides one way to perform
identity preserving queries as demanded by Requirement 3.4.12 "Identity
Preserving Queries" (see also response to XSL-Comment-021).
In the next version of the XML Query Requirements Document we
will refer to DOM 2.0 as the latest version.

XSL-Comment-005: XML Query Syntax
----------------------------------

In Section "Comments by Section" the XSL-WG writes:
<comment>
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.
</comment>

<requirements>
3.2.1 Query Language Syntax 

The XML Query Language MAY have more than one syntax binding. One query
language syntax MUST be convenient for humans to read and write. One query
language syntax MUST be expressed in XML in a way that reflects the
underlying structure of the query.
</requirements>

XML Query WG response: This requirement stems from the charter of
the XML Query WG (http://www.w3.org/1999/07/query-charter):
"The goal of the XML Query Working Group is to produce a formal data
model for XML documents with Namespaces (based on the XML Infoset), a set
of query operators on that data model (a so-called algebra), and then
a query language with a concrete canonical syntax based on the
proposed operators. According to W3C guidelines, such syntax should
be expressed in XML". 
Embeddings of XML Query into particular protocols or URI-schemes are not
planned for XML Query 1.0. However perhaps joint work on XPath can
go in this direction.

XSL-Comment-006: Declarativity
-------------------------------

In Section "Comments by Section" the XSL-WG writes:
<comment>
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.
</comment>

<requirements>
3.2.2 Declarativity 

The XML Query Language MUST be declarative. Notably, it MUST not enforce a
particular evaluation strategy.
</requirements>

XML Query WG response: This comment is noted, but has no impact on the
requirements document.

XSL-Comment-007: Fallback Strategy
-----------------------------------

In Section "Comments by Section" the XSL-WG writes:
<comment>
Section 3.2.4

Is the lack of a mention of a fall-back strategy intentional? 
</comment>

<requirements>
3.2.4 Error Conditions 

The XML Query Language MUST define standard error conditions that can occur
during the execution of a query, such as processing errors within
expressions, unavailability of external functions to the query processor,
or processing errors generated by external functions.
</requirements>

XML Query WG response: If "fall-back strategy" means that handlers for
error-conditions are defined, XML Query 1.0 indeed does not plan to
normatively define a fall-back strategy.

XSL-Comment-008: Infinite Instances
------------------------------------

In Section "Comments by Section" the XSL-WG writes:
<comment>
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.
</comment>

<requirements>
3.2.6 Defined for Finite Instances 

The XML Query Language MUST be defined for finite instances of the data
model. It MAY be defined for infinite instances.
</requirements>

XML Query WG response: The MAY for infinite instances was in particular
introduced for expressing queries on streams (see also usage scenario 2.5)
with no fixed EOF. Expressing filters on streams is regarded as useful but
ambitious, therefor the requirement is formulated only as a MAY-
requirement. There is no contradiction to closure 3.4.18. If defined on
streams, queries can produce streams.

XSL-Comment-009: XML Query Datamodel
-------------------------------------

In Section "Comments by Section" the XSL-WG writes:
<comment>
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.
</comment>

<requirements>
3.3.1 Reliance on XML Information Set 

The XML Query Data Model relies on information provided by XML Processors
and Schema Processors, and it MUST ensure that it does not require
information that is not made available by such processors. For XML
constructs found in XML 1.0 or the Namespaces Recommendation, the XML Query
Data Model MUST show how the equivalent XML Query Data Model constructs are
are defined in terms of items in the XML Information Set. The XML Query
Data Model SHOULD represent all information items, or provide justification
for any information items omitted. For information found in the XML Schema,
such as datatypes, the Data Model MUST coordinate with the XML Schema
Working Group to ensure that schema processors may be relied on to provide
the information needed to construct the Data Model.

3.3.2 Datatypes 
The XML Query Data Model MUST represent both XML 1.0 character data and the
simple and complex types of the XML Schema specification.
</requirements>

XML Query WG response: The XML Query WG welcomes coordination of efforts,
and invites the XSLT WG to review the XML Query Datamodel document -
in particular Appendix A http://www.w3.org/TR/query-datamodel/

XSL-Comment-010: Collections
-----------------------------

In Section "Comments by Section" the XSL-WG writes:
<comment>
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.
</comment>

<requirements>
3.3.3 Collections 

The XML Query Data Model MUST represent collections of documents and
collections of simple and complex values. (Note that collections are not
part of the current XML Infoset.)
</requirements>

XML Query WG response: Yes, "collections of simple and complex values"
means "collections of instances of simple and/or complex type". What
kind of collections does XSLT need to support?

XSL-Comment-011, XSL-Comment-020: References
----------------------------------------------

In Section "Comments by Section" the XSL-WG writes:
<comment>
Section 3.3.4

The XSL WG would like some clarificaton on what functionality is being
talked about.
</comment>

<requirements>
3.3.4 References 

The XML Query Data Model MUST include support for references, including
both references within an XML document and references from one XML document
to another.
</requirements>

and

<comment>
Section 3.4.11

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

<requirements>
3.4.11 References 

Queries MUST be able to traverse intra- and inter-document references. 
</requirements>

XML Query WG response: In addition to the navigation along the tree
structure covered by other requirements, this in particular may cover
navigation along id (cf. id() in XPath), and via keyref for
intra-document references, and navigation (for example by URI
and or XLink) to other documents.

XSL-Comment-012: Schema Availability
-------------------------------------

In Section "Comments by Section" the XSL-WG writes:
<comment>
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?
</comment>

<requirements>
3.3.5 Schema Availability 

Queries MUST be possible whether or not a schema is available (in this
document, the term "schema" may refer to either an XML Schema or a DTD). If
a schema is available, the data model MUST represent any items which they
define for their instances, such as default attributes, entity expansions,
or data types. These items will not be present if a schema is not present.
</requirements>

XML Query WG response: "Available" means "present" and "actually applied
to validate a document". "Must represent" indeed means "must
represent", not only "must be able to represent".

XSL-Comment-013: Text Queries
------------------------------

In Section "Comments by Section" the XSL-WG writes:
<comment>
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?
</comment>

<requirements>
3.4.2 Text and Element Boundaries 

Operations on text MUST be applicable to text that spans element
boundaries.
</requirements>

XML Query WG response: This requirement requests essentially that element-
boundaries can be ignored in queries. The XML Query Requirements Document
deliberately does not specify the XML Query Data Model. For a representation
of simple types (among them strings), please see the XML Query Data Model
Document (http://www.w3.org/TR/query-datamodel/). 

The XML Query WG anticipates that this requirements will be met by algebra
operations over the query data model, rather than by redundantly carrying
text
without element boundaries in the data model.  We shall be considering these
operations in the near future and would welcome co-operation in defining
appropriate functionality.

XSL-Comment-014: Quantifiers
-----------------------------

In Section "Comments by Section" the XSL-WG writes:
<comment>
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.
</comment>

<requirements>
3.4.3 Universal and Existential Quantifiers 

Operations on collections MUST include support for universal and
existential quantifiers.
</requirements>

XML Query WG response: The XML Query Group welcomes collaboration on
shared requirements.

XSL-Comment-015: Sequence
--------------------------

In Section "Comments by Section" the XSL-WG writes:
<comment>
Section 3.4.4

Does "sequence" mean "document order"? 
</comment>

<requirements>
3.4.4 Hierarchy and Sequence 

Queries MUST support operations on hierarchy and sequence of document
structures.
</requirements>

XML Query WG response: No, sequence means the sequence of sibling
elements. Document order can be inferred from hierarchy and
sequence but not vice versa. Thus operations on document order
can be built from operations on hierarchy and sequence.

XSL-Comment-016: Combination
-----------------------------

In Section "Comments by Section" the XSL-WG writes:
<comment>
Section 3.4.5

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

<requirements>
3.4.5 Combination 

The XML Query Language MUST be able to combine related information from
different parts of a given document or from multiple documents.
</requirements>

XML Query WG response: Relationships among "related information"
comprise any (mathematical) relation between two information
items from one or more documents that XML Query can express by
boolean operators (predicates).

XSL-Comment-017: Aggregation
-----------------------------

In Section "Comments by Section" the XSL-WG writes:
<comment>
Section 3.4.6

What kinds of aggregation will be supported? Some examples would be
helpful.
</comment>

<requirements>
3.4.6 Aggregation 

The XML Query Language MUST be able to compute summary information from a
group of related document elements (this operation is sometimes called
"aggregation.")
</requirements>

XML Query WG response: Typical examples (from the SQL-world) are
average or maximum. However, the requirements document deliberately
does not enumerate an exhaustive list of aggregation functions.

XSL-Comment-018: NULL-Values
-----------------------------

In Section "Comments by Section" the XSL-WG writes:
<comment>
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.
</comment>

<requirements>
3.4.8 NULL Values 

The XML Query Language MUST include support for NULL values. Therefore, all
operators MUST take NULL values into account, including logical operators.
</requirements>

XML Query WG response: The XML Query WG group welcomes collaboration with
the XSLT WG and the XML-Schema WG on the support of NULL values.

XSL-Comment-019: Transformations
---------------------------------

In Section "Comments by Section" the XSL-WG writes:
<comment>
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.
</comment>

<requirements>
3.4.10 Structural Transformation 

Queries MUST be able to transform XML structures and MUST be able to create
new structures.
</requirements>

XML Query WG response: This includes both. Transformations that
produce copies and transformations that produce references to
the original XML nodes are planned for XML-Query.
The result will be in any case an instance of the XML Query Data
Model (http://www.w3.org/TR/query-datamodel/) rather than an XSLT
result fragment.

XSL-Comment-021: Identity Preservation
---------------------------------------

In Section "Comments by Section" the XSL-WG writes:
<comment>
Section 3.4.12

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

<requirements>
3.4.12 Identity Preservation 

Queries MUST be able to preserve the identity of items in the XML Query
Data Model.
</requirements>

XML Query WG response: The XML-Query Data Model does not use the notion
of "result set" but regards results as well as inputs as instances
of the data model. As also stated in the response to XSL-comment-019,
queries should be able to return both, copies and identity preserving
references to information items.

XSL-Comment-022: Literal Data
------------------------------

In Section "Comments by Section" the XSL-WG writes:
<comment>
Section 3.4.13

This needs to be clarified. What does "literal data" mean?
</comment>

<requirements>
3.4.13 Operations on Literal Data 

Queries SHOULD be able to operate on XML Query Data Model instances
specified with the query. We refer to such data as "literal data" in this
document.
</requirements>

XML Query WG response: The XML Query Working group agrees, this needs
clarification. See also:
http://lists.w3.org/Archives/Public/www-xml-query-comments/2000Mar/0006.html
In the next version of the requirements document we will add a glossary term
for literal data:

"Literal Data": literal fragments of an XML document such as
<name><first>Jim</first><last>Doe</last></name>, which may
be used for comparison in a query.

XSL-Comment-023: Operations on Names
-------------------------------------

In Section "Comments by Section" the XSL-WG writes:
<comment>
Section 3.4.14

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

<requirements>
3.4.14 Operations on Names 

Queries SHOULD be able to operate on names, such as element names,
attribute names, and processing instruction targets, and to operate on
combinations of names and data.
</requirements>

XML Query WG response: The XML Query Working group agrees, this needs
some clarification. See also:
http://lists.w3.org/Archives/Public/www-xml-query-comments/2000Mar/0006.html
<response>
The query language WG agrees that simple operations on names such as tests
for equality in element names, attribute names, and processing instruction
targets, and tests on the combination of names and data are very common and
a MUST. We will change the requirement accordingly.
</response>

XSL-Comment-024: Operations on Schemas
---------------------------------------

In Section "Comments by Section" the XSL-WG writes:
<comment>
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.
</comment>

<requirements>
3.4.15 Operations on Schemas 

Queries SHOULD provide access to the XML schema or DTD for a document, if
there is one. If the schema is represented as a DTD, a mapping to an
appropriate XML Schema representation MAY be required.
</requirements>

XML Query WG response: The XML Query WG welcomes collaboration on this
effort.

XSL-Comment-025: Extensibility
-------------------------------

In Section "Comments by Section" the XSL-WG writes:
<comment>
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.
</comment>

<requirements>
3.4.16 Extensibility 

The XML Query Language SHOULD support the use of externally defined
functions on all datatypes of the XML Query Data Model. The interface to
such functions SHOULD be defined by the Query Language, and SHOULD
distinguish these functions from functions defined in the Query Language.
The implementation of externally defined functions is not part of the Query
Language.
</requirements>

XML Query WG response: The XML Query WG only became aware of the XSLTEX-
draft (W3C member only) and looks forward to reviewing this work with
interest. 

XSL-Comment-026: Relationship to XSTL/XPointer/XPath
-----------------------------------------------------

In Section "Comments by Section" the XSL-WG writes:
<comment>
"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.
</comment>

<requirements>
XSL, XPointer 

Both XSLT and XPointer use XML Path Language (XPath), which defines a
location path syntax that can be used to search for matching parts of an
XML document. The XML Query work will take into consideration the
expressibility and search facilities of XPath when formulating its algebra
and query syntax, and wherever possible try to encompass those
functionalities into its query language.
</requirements>

XML Query WG response: The XML Query WG will change the heading
accordingly to "XSL and XML-Linking Working Groups" to reflect
the working groups responsible for the mentioned specification more
concisely.
As stated in the requirements document, the XML Query WG considers XPath to
be an important input to XML-Query. But as a requirements document the XML
Query Requirements Document does not commit to any particular syntax, be it
XPath or S/OQL-pathexpressions or anything else. Likewise, the (syntax-
independent) formal algebra does - by definition - not commit to a
particular syntax.


Paul Cotton, Microsoft Canada
17 Eleanor Drive, Nepean, Ontario K2E 6A3
Tel: (613) 225-5445 Fax: (613) 226-6913
Email: mailto:pcotton@microsoft.com

Received on Tuesday, 6 June 2000 23:02:47 UTC