What should be data-model representation, if any, of PSV Infoset identity-constraint tables?

This function assumes that the character information items for an atomic value (e.g., string, integer, floating-point number) are not interleaved with other information items (e.g., PIs or comments). The treatment of such interleaved values is not handled in this definition. This issue is addressed in threads beginning at: http://lists.w3.org/Archives/Member/w3c-archive/2000Jun/0090.html (members only) and http://lists.w3.org/Archives/Member/w3c-xml-query-wg/2000Sep/0079.html (members only).

Remark Michael: An IDREF cannot point to an empty string.

A document may refer to a DTD and have an associated schema. Currently, content model from the DTD is ignored, as are unique IDs from the schema. A coherent priority or merging strategy is needed.

Any strategy developed must also address the issue of types derived from xs:ID.

The current data model draft takes only into account singleton value-nodes. It must represent lists of simple-type values as well. See http://lists.w3.org/Archives/Member/w3c-xml-query-wg/2000May/0060.html (members only).

Peter suggests having a special-purpose kind of a TextNode that represents lists of simple types. An advantage of this approach is that the constraint that lists of simple types be homogeneous/monomorphic can be enforced. However, lists/forests already can be modeled in current data model, without adding more complexity. For example, an attribute's value could be modeled as a list of TextNodes:

value : (AttributeNode) -> Sequence<TextNode>

A disadvantage of this approach is that the monomorphism constraint on lists derived from simple types is not enforced. However, given a type system for Query, such a constraint could be enforced. So Mary is in favor of not having a special-purpose kind of TextNode to represent lists, but instead model them by forests directly in the data model.

JM: note that the pseudo-code doesn't appear to handle schema list values.

We need a more thorough definition of collections, perhaps in a separate section, which includes bags and defines collections formally.

In particular, the algebra (probably) will not support arbitrarily nested collections (i.e., lists of lists, sets of sets, etc.). We need to specify how collections are constructed. For example, in the data model, the basic collection is a forest, i.e., a list of Nodes. The forest constructor creates a singleton forest from one Node; or it creates a forest from two forests by concatenating the two forests:

Similar constructors would exist for bags with and without duplicates.

unordered : (Forest) -> NodeBag unique : (NodeBag) -> NodeSet set = unique o unordered : (Forest) -> NodeSet

An alternative representation is to have a single TextNode whose base type is string:

text-node : (xs:string, S, Sequence<Node>) -> TextNode

This representation is more closely aligned with other node types in the data model, but it makes the simple type of leaf-node values opaque.

Peter Fankhauser compares and constrasts these options in : http://lists.w3.org/Archives/Member/w3c-xml-query-wg/2000Apr/0174.html (members only).

Cite:

Let me summarize my issues with a node-centric datamodel right at the beginning. The first two are mentioned in the doc later on:

As long as (1) the data represents a tree, (2) easy bi-directional is not required, (3) projection/extension operations with object-preserving semantics are not required, a node-centric datamodel is isomorphic to an edge-centric datamodel and is easier to represent and understand.

As soon as anyone of the above requirements change, an edge model has several advantages:

Cite:Sometimes one wants to use different schemata over the same basic XML fragment. So I would rather start with that in principle, the data model is schemaless and can provide the data model of any XML fragment given a schema. Thus, the schema postprocessing becomes a datamodel transformation that we make explicit (and that could be optimized with other operations that transform the datamodel graph).

Should the data model require that an implementation guarantee that the identity of a node is always preserved?

In XML Schema, facets such as "nullable" is associated with an element declaration, which is an element name, complex type pair. If the query language needs access to such facets, we may need to replace ReferenceNode by a reference to the element declaration.

Cite: The current representation of reference values is too much IDREF(S) centric. I would prefer a more general representation for XLink and the schema (and potentially graph operation) introduced reference mechanisms.

Equality operators '=' on collections are not defined.

Should the element constructor element-node also permit bags of children?

The semantics of the value equality operator '=' are undefined.

Code is undefined.

The relationship between ordered and unordered collections is not specified. Any ordered collection can be treated as an unordered collection.

How are IDREF lists and NMTOKEN lists represented in data model.

An alternate is to separate element construction from schema validity assessment. The element constructor would construct an element corresponding to the an element information item in the Infoset before schema validity assessment. To produce elements with types, the schema-process function would schema process an element with respect to a schema type to yield a new element with the full PSV infoset. The schema-process function would ignore any type information on attributes and elements and would assess the untyped value with respect to the given type.

element-node : (xs:QName, Sequence<NamespaceNode>, Sequence<AttributeNode>, Sequence<ElementNode | ProcessingInstructionNode | TextNode | CommentNode>) -> ElementNode schema-process : (ElementNode | AttributeNode, SchemaComponent) -> ElementNode | AttributeNode

Deep copy on a node is defined only informally. For example, does deep copy preserve base URI?

Currently, an element node preserved its declared namespace nodes, not its in-scope namespaces. Members of the XSLT WG point out this may make impossible to determine the meaning of data-model values that refer to the default namespace. This is a big, nasty problem.

The representation of run-time type information is very concrete -- it's the data model representation of a Schema type. The XPath task force would like a more abstract representation of runtime type that is not bound so tightly to XML Schema. This is an open design problem.

Many people would like to see support for document repositories in XPath 2.0 with a corresponding notion in the data model. A document repository is easy to model as a sequence or bag of document nodes. It may have some additional properties, like for an ordered repository, order among all the nodes in the repository.

In its current state, the data model clearly does not cover schema-invalid documents: section 3.3 says "We assume that the element is an instance of the type represented by Def-Type, i.e., the document 'type checks' or is valid with respect to the given schema."

I believe we may wish to extend / modify the data model to specify that:

This would allow / require schema systems to be robust in the face of invalid documents. At first glance, that seems like a win.

Should sequence values carry their type as do simple typed values and element and attribute nodes?

If schema component values becomes nodes, then does that mean they can occur any where in a document tree? I.e., can they be children of other nodes? What does this mean when a data model is serialized as a document?

Given a simple-typed value, it may be necessary to recover its lexical representation, for example, when creating a text node that contains the value. It is not always possible to compute a unique lexical representation of a simple typed value.

Whitespace handling needs to be more explicit. In the presence of a schema we have full knowledge of which whitespace is significant and which isn't, and can either mark whitespace as insignificant (and thus exclude it from text() and string-range() for instance), or automatically suppress whitespace in the data model. The former is appropriate given the dual representation of text nodes and values, the latter is appropriate if we only expose values.

Reference nodes may be part of the data model, but will never appear from a mapping from the infoset. In addition they cannot be serialized. Without these two features there doesn't seem to be much point in having them. Should we leverage an existing syntax (e.g. IDREFS) or design a new syntax to represent them?

With external entities, and now with XML Base, the base URI can be scoped to various parts of the document. A base URI property should be added to Element Nodes, and the constructor and infoset mapping updated. Otherwise relative URIs in content cannot be correctly resolved.

Processing instructions also require an infoset-derived base URI. The base URI of attributes, for instance, should probably not be the empty sequence, if that does not adequately imply that the base URI of the element should be used instead.

Schema component does not reveal [content] property of schema component. MF: Problem with revealing [content] property is that we/Schema/Query have to agree on syntax for component content (Sec 2.2.1 in ).

Note that the data model does not currently represent key values and key reference values as described in XML Schema Part 1 : Structures . In a future draft of this document, keys and key references will be represented in the data model.

http://lists.w3.org/Archives/Member/w3c-xsl-query/2001Apr/0312.html (members only). Asks for inference rules, especially for the constuctor, describing when values returned by an accessor are the same as those set by the corresponding constructor. Especially unclear are when adjacent text nodes are collapsed, base URI and namespace declarations.

http://lists.w3.org/Archives/Member/w3c-xsl-query/2001May/0053.html (members only). Clarify whether whitespace is classified as insignificant before or after PI and comment removal.

http://lists.w3.org/Archives/Member/w3c-xsl-query/2001May/0054.html (members only), http://lists.w3.org/Archives/Member/w3c-xsl-query/2001May/0048.html (members only). Simplify operations such as distinct() by disallowing sequences mixing nodes and simple typed values. Suggests converting nodes in such a heterogeneous sequence to their typed values.

xsd:anySimpleType (and other abstract types) are not supported in the data model. The string-value of an xsd:anySimpleTyped is apparently the empty sequence - indicating that you can't really do useful operations on anySimpleType'd values. However, we apply a default schema which assigns xsd:anySimpleType, resulting in a proliferation of these types. How can we operate on these documents? Should we at least return a non-empty string-value() for an anySimpleType? Should we define additional operations such as +, *, for compatibility with XPath 1.0?

Define (somewhere other than the data model document?) axis functions for non-primitive axes like descendants-or-self.

From XPath 1.0: "If an XML processor reports two elements in a document as having the same unique ID (which is possible only if the document is invalid) then the second element in document order must be treated as not having a unique ID." This has not been incorporated into this document.

In XPath 1.0 namespace nodes have a parent. Should we adopt the XPath 1.0 behavior, the current behavior (no parent), or some other parent (e.g. the document)?

[Jim] found [him]self wondering how those flags (parameters) get set/passed. More importantly, can a process ask whether "this instance" of the data model has those flags set or not? If so, how? If not, why not?

What are the use cases for being permissive about children of the document node? According to the note above, sequences of elements do not need a container node. Suggest removing this permissiveness.

In our model, there is no way for a query to determine what DTD is relevant for the data model instance. That seems like a piece of information that might be wanted occasionally (though probably not often).

In some cases, when an accessor is inappropriate for a node, we omit that accessor. In other cases, we define it to always return the empty sequence. We need to rationalize these two design patterns.

The unique ID property is defined on an element node, but is a function of an attribute information item. When an element node is constructed it is given an attribute node - not an info item. An attribute node is insufficient to remember the appropriate properties from the infoset in order for the element constructor to detect when an attribute is an ID declared in the DTD.

The Character Model for the World Wide Web version 1.0 working draft defines W3C-normalized text. The algorithm for constructing text nodes from character information items does not perform normalization to this form. Should it?

In XML Schema, the type unsignedInt is a simple type, but it's a derived type (not a primitive type); the nearest corresponding primitive type is decimal. If I were to invoke the value accessor with something analogous to "value(cast as unsignedInt('10'))", does it return a decimal value, and is the SchemaComponent returned by type a component that describes decimal? I do not believe that this a non-issue because the only types supported in the data model are XPath 1.0's types (string, number, boolean, and node-set), since this document makes a strong point about using all of Schema's simple types. Thus, does value return the primitive value, or does it return something like the schema-normalized value of the specified simple type?

The possibility that generating sequences in which one or more members are Error may sometimes be a useful way to produce partial results that can satisfy some sorts of queries.

I am very concerned that "How the error value is handled in a query processor is implementation-defined." I think we have to do a bit better than this, although leaving flexibility for implementations to do more for their users is a Good Thing.

MF cite James: An alternative would be to have an extends accessor that returns deref([base]) if [derivation] is extension and empty sequence otherwise, and a restricts accessor that returns deref([base]) if [derivation] is restriction and empty sequence otherwise.

Are newly-constructed nodes in any particular order, such as some kind of document order? Does the order of these nodes have any relationship to the document order of the "input" data model instance? In fact, is the process being described properly characterized as "create a new data model instance from information derived from an existing data model instance", or something similar? Can more than one "new" document instance be created by a single query? In the fourth paragraph [Section 4], we see the phrase "the document node" --- is this the "existing document"'s document node, the "new document"'s document node, both, neither? Can more than one "existing" document instance be the source of information for a query?

Section 3.2 states that in the document ordering, the namespace nodes of an element follow the element but precede its attributes. This is inconsistent with the idea, suggested but not spelled out in 4.4, that a namespace node can be shared by several elements. In fact, the question of namespace node identity is not really tackled. My view is that namespace node identity should be determined by the combination of (document identity, namespace prefix, namespace URI), that the parent of a namespace node should be the document node, and that namespace nodes should be ordered after every other node in the document. (This is easier for implementations than placing them at the start of the document, because the number of namespace nodes is not known until parsing is complete).

In section 4.2 Elements, the notion that the constructor makes a copy of the supplied child nodes seems strange. It's hard to square this with the definition of node identity. Also, I don't see why the provision is needed here, but not for the document node constructor. Wouldn't it be cleaner to define a precondition that all the child nodes supplied to the constructor must be parentless?

Head would appear to be a partial function, it does not apply to empty sequences. If we follow the same conventions as elsewhere, that means head returns a Sequence(0,1)<item>, which perhaps begs the question as to how you extract the first member of this sequence...

Currently, the typed-value of a complex type is the empty sequence. Should complex types with simple content (i.e. an element that contains only text but that also has an attribute) be treated differently than complex types with complex content?

The XSL WG wishes xsi:nil="true" to result in a typed-value of the empty sequence. This allows the differentiation of a null string value and an empty string.

Summary: The only necessary operation on Schema Components is instance-of(schema-component1, schema-component2). There is no need to expose the internal structure of Schema Components to enable this functionality. Instead we could provide an abstract Type object whose internal structure can be treated as a black box. See http://lists.w3.org/Archives/Member/w3c-xsl-query/2001Jul/0042.html (members only).

XSLT allows a stylesheet to designate elements whose whitespace is to be stripped. We need to support this in the data model, or possibly elsewhere.

Similarly, a data model instance for a stylesheet has provisions for stripping comments and processing instructions.

Node constructors. I'm a bit concerned that this is lacking in rigor. Some of this is exposed in . The idea that the constructor for a parent node (Element or Document) takes a copy of the supplied children node doesn't seem to be fully worked out. What does "taking a copy" mean, where is it defined? It has to be a deep copy to make sense; it has to preserve its name, its type, and its children, but not its base URI or its node identity, and it acquires a new position in document order. What happens about the namespace nodes when an element or attribute is copied? Altogether, I'm worried that this idea of node constructors looks formal, but is actually just as informal as the 1.0 specification. It's actually a very procedural description, and I can't really see why it's needed: if it's intended as a target vocabulary for the formal semantics of the language, then it's a pretty shaky foundation. I'd be much happier with a model that only defines the valid states in the system; if we are going to define the permitted state transitions, we need to be much more rigorous about it.

"The sequence-map function applies its first function argument to each member of its second sequence argument and returns a new sequence containing the result of applying the function to each member of the sequence." I really wonder whether it is a good idea to define the data model using a pseudo-formal language that we make up and half-explain as we go along? If we can't use an existing formal notation like Z or VDM that has a good specification we can reference, we should do the whole thing in English.

We need to say something about the identity of namespace nodes, and about the fact that two namespace nodes for the same prefix and uri may need to be combined when an element is added to a document. Also "the element constructor logically creates a copy of all of its namespace..." - namespace nodes do not need to be copied(?)

An observation: if an attribute node has no parent element (a floating attribute), then there is also no access to any namespace nodes. This makes it impossible to support the XPath 1.0 name() function, which returns a lexical QName for the node by finding a prefix that maps to the node's namespace URI.

[JM: Sounds like we need a QName object that is a triple, local-name, namesapce-uri, and prefix, to support XSLT.]

The current XSLT draft includes a substantial piece of text on namespace fixup. This was introduced in the XSLT 1.1 working draft, and is basically designed to ensure that when an element or attribute is added to a result tree, namespace nodes are also added to declare any namespace URI used by the element or attribute. (At XSLT 1.0, this was handled at serialization time, but this had to change when temporary trees became accessible to the stylesheet). The description of namespace fixup logically belongs with the description of the node construction process in the data model document. http://lists.w3.org/Archives/Member/w3c-xsl-query/2001Oct/0036.html (members only).

Although XSLT and the XPath 2.0 data model agree that element and attribute nodes do not hold a namespace prefix, XSLT has always hinted that prefixes might be preserved through a transformation where possible. http://lists.w3.org/Archives/Member/w3c-xsl-query/2001Oct/0036.html (members only).

[JM: the ability to recover the lexical value of an xs:QName simple type seems useful, perhaps even necessary. It is at least needed to support the name() function. A better description of the xs:QName accessors is required, perhaps unifying xs:QName and expanded-QName.]

The constructor for the element node probably should include the type definition in the constructor as well, for cases where the [type definition] of the element information item is not the same as the [type definition] of the [element declaration], which can occur if xsi:type is used in the document. Should the same be done for attribute node constructors for consistency, (even though attributes cannot have xsi:type attributes)? http://lists.w3.org/Archives/Public/www-xml-query-comments/2001Sep/0012.html.

The element and attribute constructors are not convenient when constructing elements or attributes with simple-type content. An alternative constructor that takes a typed value directly (instead of only text nodes or normalized string values) would simplify dependent specifications. http://lists.w3.org/Archives/Member/w3c-xsl-query/2001Nov/0068.html (members only).

SchemaComponents currently don't expose any substitution group information. http://lists.w3.org/Archives/Member/w3c-xml-query-wg/2001Nov/0358.html (members only).

The syntax of the function calls need to be aligned with the other working documents, in particular the Functions and Operators and the XQuery documents. Possible candidates are f:(T1,T2)->T or f(T1 $v1, T2 $v2)=>T.

When a sequence of heterogeneous simple typed values is passed as the content of an element constructor, is the type information associated with the simple typed values preserved? e.g. when using a sequence containing a decimal, a string and a boolean are these types preserved (or possibly changed to anySimpleType* ?). Note that XML Schema cannot describe this former. Related to this, should we ever allow an element constructor to create an instance that can not be serialized as XML text without loss of type information?

Should derived types have a canonical form? Should we ask XML Schema to fix this?

Should the name accessor return "" or () for nodes that have no name?

Should the following attributes be represented in the data model? xmlns attributes, xml:lang, xml:space, xsi:nil (etc). If so, how?

Unfortunately the XML Schema Datatypes Rec doesn't detail the canonical lexical representation of all of the primitive types. In particular, no canonical lexical representation is specified for:

http://lists.w3.org/Archives/Public/www-xml-query-comments/2002Jan/0268.html

Currently the data model says that the string value of an attribute node is normalized (according to the whitespace facet of its type); on the other hand, the string value of an element node is not normalized. The string value of elements with simple content should also be normalized in the same way as the string value of attributes. http://lists.w3.org/Archives/Public/www-xml-query-comments/2002Jan/0269.html

Currently the Document node in the data model is permissive in the number of element nodes it can directly contain whereas the infoset only allows a single element node. Since preserving the single element node constraint is important to enforce queries to generate only well-formed documents when generating documents, the question is whether the data model needs to introduce a docfragment node that is permissive and keep the document node to be non-permissive. See http://lists.w3.org/Archives/Member/w3c-xsl-query/2002Feb/0111.html (members only).

XSL WG has a requirement to access unparsed entities in a document. This is needed to support the XSLT 1.0 unparsed-entity-uri() function, and the unparsed-entity-public-id() function which we are adding for XSLT 2.0. In XSLT 1.0, unparsed entities were not described in the XPath data model, but in an XSLT addition to the data model. This solution is unsatisfactory: the data model should describe all the information that is available. The information is available in the InfoSet so there is no architectural problem in providing it. There is room for debate about how it is best provided (we don't really want another node type if we can help it), but the information should be there. We are not proposing, at this stage, that the functions unparsed-entity-uri() and unparsed-entity-public-id() be moved from XSLT into XPath, though that can easily be done if people want them. The information about unparsed entities in the data model would therefore not be available to XQuery users or to XPath users outside an XSLT environment.

The last bullet in the definition of the PSVI to Type mapping does not handle derived types properly. In those cases we should not bottom out at xs:anyType, but attempt to use the rules all over again with the type from which the current type is derived. Also note that these rules need to be slightly different if we decide to use generated type identifiers when no type names are available.

The rules specifying the computation of the types from the PSVI do not yet reflect that this process depends on the conformance level of the processor. For Basic, are any type annotations preserved? The Query/XPath book says the data types are mapped to the nearest supertype, the Data Model needs to agree with this.

It is not clear how the current data model can represent or accomodate CDATA sections. (This is also captured as Issue 0293 on the XPath issue list.)

Note that the current definition of string-value($n) is such that it may differ from string-value(dm:typed-value($n)) for some element or attribute nodes $n. For instance given a node element-node(my:a,(),(),dm:text-node("01"),xs:integer), its string-value gives "01", but the string-value of the typed-value is "1".

The possible resolutions are that we (a) prohibit, (b) allow or (c) mandate string-value($n) to be string-value(dm:typed-value($n)). The current text reflects (a). Option (b) would result in non-interoperable implementations. Option (c) is promising. In that case the element constructor would need to be a little smart and change the textnode to contain the string value of atomic-value-sequence applied to the string-value of the original text node and the type passed to the constructor. Similar change would need to be done to the attribute constructor.

There is currently an asymmetry between the data model and the F&O documents. In the data model, the typed-value accessor on document, comment, PI nodes returns the empty sequence. In the F&O document, the data() function applied to a document, namespace, comment or processing instruction node, raises an error.

My intuition is that data() should be defined on all nodes, just as string-value() is defined. Raising an error on document, comment, PI, seems draconian and has tripped me up in writing queries that iterate over a variety of nodes. If data() returns error on such nodes, one ends up with a lot of code checking what kind of node is bound to a variable, etc.

If a document has a DTD, do we really have to lose the IDness of all ID attributes and other information that's available from DTD validation?

Note that currently the last bullet point cannot be reached from a legal PSVI because every element in a PSVI must have one of the combinations of properties listed. Elements whose type definition is anonymous still have a [type definition] property, it's just that the type definition's [name] is absent (the property exists, I think, but it has no value). Under the scheme above, such elements would have type whose namespace was the target namespace of the schema and whose name was nothing. http://lists.w3.org/Archives/Public/public-qt-comments/2002Aug/0018.html

I'm not sure what distinction you're making between [name] and {name}. As I understand it in the XML Schema spec, {name} is a property on a schema component while [name] is a property on an information item in the PSVI. Since you're talking about properties in the PSVI, I believe you should be using the notation [name] rather than {name}. http://lists.w3.org/Archives/Public/public-qt-comments/2002Aug/0018.html

Suppose I have an attribute that has the type xs:ENTITY and the value "foo". How can I find out the public and system identifiers of the external unparsed entity "foo"?

There is an open issue about how to map namespaces declared globally in the query prolog during the data model to infoset transformation.

This issue replaces an editorial note in the previous draft that said there was an issue.

Does the constraint that the same set of nodes is returned restrict the possibilities for implementation? Should this constraint be relaxed?

For instance, an XML 1.0 store such as a DOM stores namespace information as attributes, and has no mechanism for undeclaring arbitrary namespaces. If a series of constructor functions are called to construct a data model instance that has fewer namespaces on children then on a parent element, the store will be unable to represent this, and might return extra namespace nodes. I claim (without proof :-) that these extra namespace nodes are harmless, and constraining implementations in this way is a burden.

Calling base-uri on a node that has no (transitive) base URI property raises an error. Would it be better to return ()?

See http://lists.w3.org/Archives/Member/w3c-xsl-query/2002Oct/att-0275/01-2002-10-16-pres.html.

Calculating the value of element content whitespace requires knowing the element's content type which doesn't seem to be available.

I don't think the spec is clear enough on how typed-value is calculated. I think the following proposal would work, but perhaps I'm wrong or perhaps we've already got another proposal somewhere else.

I notice that there's a requirement that a document node has at least one child. This seems to have been in previous drafts, but I overlooked it. In XSLT it's legal to create a document node with no children.

http://lists.w3.org/Archives/Member/w3c-xsl-wg/2002Nov/0005.html

I suggest that we add a dm:substitution-groups() accessor to the data model that returns a sequence of xs:QNames derived from the {substitution group affiliations} of the [element declaration] reported for the element and use this list to work out whether an element "has been validated and found to be a member of a substitution group whose head element has the required name" rather than guessing on the basis of the element's name (and type).

http://lists.w3.org/Archives/Member/w3c-xsl-query/2002Nov/0007.html.