W3C home > Mailing lists > Public > www-forms@w3.org > November 2002

RE: XForms CR - 3.3.2 "one and the same"?

From: Mark Birbeck <Mark.Birbeck@x-port.net>
Date: Wed, 13 Nov 2002 14:43:28 -0000
Message-ID: <E3ED00A7C285EE408679DE2A26D1C781365E12@S007.x-port.net>
To: "'AndrewWatt2001@aol.com'" <AndrewWatt2001@aol.com>
Cc: www-forms@w3.org, www-forms-editor@w3.org, Xforms@yahoogroups.com

Hi Andrew,

Andrew wrote:
> In 3.3.2 the sentence, "We also seek feedback on 
> self-referential cases where 
> the instance data and the containing document are one and the 
> same." is used 
> to refer to an open issue.
> 
> Since, to the best of my knowledge, instance data can (more 
> or less) only 
> exist when an <xforms:instance> element is nested within an 
> <xforms:model> 
> element I don't see how the "instance data" and the 
> "containing document" can 
> ever be "one and the same".

I don't think there's anything wrong here Andrew. I took it to mean that the
instance data referred to by the URL was the document itself. The issues
raised are obviously to do with what happens if you edit this instance data,
since in some senses you could regard that as editing the document itself.

The spec points out that as things stand, editing the instance data would
have no effect on the containing document. This is obviously important to
retain as the default behaviour since we must have a separation between the
data to be edited, and the thing doing the editing. Even if you edit the
editor, you don't want the editor to change underneath you until you have
finished editing it ...! (If you see what I mean ;-))

So, if we leave that to one side, the issue then becomes, "how do we
indicate that we do indeed, want to edit the document itself"?

'THIS DOCUMENT'
I would suggest that this is not done by detection of the two URLs being the
same, since we then don't know if the form-coder wants the default behaviour
(i.e., leave the editor intact whilst editing this representation of the
editor) or the new behaviour (i.e., change me dynamically). It is also
asking for trouble with URL mappings, possible redirections, and of course
the maintenance issue of each form having to know its own address. Finally,
it will probably mess up with xml:base.

One possibility might be to use a simple '#', which is often used to mean
'this document'. We could even use an empty string, which amounts to the
same thing. Either way, we are taking advantage of the fact that this is a
relative address, thus keeping it as a valid URL, but also making it a
special case that is easy for the processor to spot. It would then be very
easy for the XForms processor to understand that what is going to be edited
is 'this document'.

I don't think the XForms spec would need to define any more than this,
though, since all operations after this are the responsibility of the
containing document. This *has* to be the case, since you won't necessarily
be editing anything that is under the control of the XForms part of a
document. The example given is an SVG graph, but it could even be something
simple like part of an XHTML document - the contents of an h1 or the style
property on a paragraph. All we are really saying is that instead of
creating an XML DOM document and reading in whatever is referred to by @src,
the processor can simply point to the root of the containing document.

In our implementation (FormsPlayer) an 'instance' object simply contains a
pointer to a DOM document - as I'm sure others do, too. It therefore
wouldn't be difficult for us to say that seeing a URL of '#' or '' would
result in this pointer being set to the XML version of the document itself -
the assumption being, obviously, that the containing document was derived
from dom::Document. This would mean that any changes to the instance data
would now be handled by the containing application, or the application that
has responsibility for part of the DOM - and either cause updates
immediately, or not.

However, to set this up you will need to know where the containing document
is. And because there has been much resistance to defining a DOM for XForms
we don't have any way of doing this. Basically, at the very least you need
the 'ownerDocument' property of 'Node', defined in DOM 2. By deriving all
XForms elements from the DOM 'Element' interface we would have access to
this. Then in turn, because all parts of XForms are derived from 'Node',
when you actually modify 'this document' through an XForms forms control,
you will be able to modify the XForms parts of the containing document's
DOM. As things stand you would not be able to do this, since there is no
required connection between the elements that define XForms forms and the
objects that provide the functionality.

(I've been putting off raising the issue of a DOM interface until other
issues were resolved, and this seems as good a time as any to raise them. I
think that previous justifications that one is not needed since we should
program declaratively are not relevant to these issues.)

Regards,

Mark


Mark Birbeck
Co-author Professional XML,
and Professional XML Meta Data,
both by Wrox Press

Download our XForms processor at
http://www.FormsPlayer.com/

Managing Director
x-port.net Ltd.
4 Pear Tree Court
London
EC1R 0DS

E: Mark.Birbeck@x-port.net
T: +44 20 7689 9232
M: +44 7774 102 413
W: http://www.x-port.net/
Received on Wednesday, 13 November 2002 09:45:25 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Saturday, 10 March 2012 06:21:54 GMT