id function

This message is in partial fulfillment of Action 20060-04-26.3 "XForms
1.1 Leigh to write up problem of id() function and whether or not it
recognises a node of type xsd:id when the type was set using an XForms
MIP."
 
We have a number of issues to explore, and should be exploring them
separately, as combining them together does not encourage clear
thinking.
Here is a first attempt at separating out these issues so that we can be
clear which ones we are discussing.
Leigh.
 
 
1. id() in XForms 1.0
1.1 In XForms 1.0, id() comes from XPath 1.0.
1.2 It does not allow specification of an instance or context node,
therefore it is not usable in anything but the default instance.
 
2. bind/@type information in XForms 1.0
2.1 The XForms 1.0 rec says that bind/@type is handled like xsi:type
2.2 The XForms 1.0 rec specifies how conflicts between bind/@type  ???
2.3 XForms Basic introduces an issue when the bind/@type specifies
simple types but the model/@schema defines a complex type, and we need
to resolve this.
The proposal in
http://lists.w3.org/Archives/Public/www-forms-editor/2006May/0000.html
to say "Issue an erratum for 6.1.1 Type property about how the type is
bound to  
the data. It mustn't be done by equivalency to xsi:type attribute." does
not address this concern, and instead makes XForms harder for authors to
understand and offers no prescription for interoperability.
 
3. id() in XForms 1.0 and ID-ness
The XPath rec says that ID-ness comes from DTDs, but XForms doesn't
support DTDs.  
In practice, few XML applications with that rely on IDs use DTDs.
XML Schema supports declaring ID-ness, but the letter of the XPath 1.0
Rec doesn't mention it.
xml:id is proposed to alleviate many of these problems by suggesting a
common spelling for ID attributes, to eliminate any need to declare
ID-ness.
But it proposes to do this with an erratum to the XPath 1.0 Rec, which
highlights the inconsistency between the letter of the XPath 1.0 Rec and
current practice.
http://www.w3.org/TR/xml-id-req/#XPath
 
4. id(a,b) in proposed XForms 1.1, from XPath 2.0, to allow the
specification of a context node.
 
5. XPath 1.0 does not allow colons in names for extension functions, but
XPath 2.0 does; in practice, implementations of XPath 1.0 universally
use colons, but XForms 1.0, since it followes the letter of the law on
XPath 1.0, does not.
 
6. XPath 2.0 might or might not allow a source of datatype information
for functions such as id().
The intent of XPath 2.0 is clearly to allow datatype declarations to be
used, and in particular XML Schema types.
There are multiple sources of data type declarations in the real world;
for example, xsi:type, an XML Schema file, and and ISO DSDL (Relax NG)
schema, all provide XML Schema types for nodes.
As XForms has a mechanism for declaring datatypes, we should work with
the XPath group to make sure that there agreement on what mechanism can
be used to propagate this type information.