Re: forms-lite and data models

Hi John,

> Well, first for Francisco, the use of id() does not work because the XPath data models
> we create are for instance data, whereas the IDs on the binds are not in instance data.
>  So even with a
> <bind id="A" ... />, the function call id('A') would return empty nodeset.

I doubt that Francisco was not aware of that, John...I read him as
merely suggesting that in some way or other we should be able to
obtain the nodeset. Given that Dave's examples use script rather than
XPath, Francisco might also have been suggesting a non-XPath solution.


> Moreover, the idea has the same problems as Mark's variable idea, and the two have
> at least one problem in common with the dot-dot problem.
>
> 1) We want authors to be able to type into expressions the names that they assigned.
>  We don't
> want XForms processors to have to parse the XPath expressions, find all the node
> references in the location paths and add  "../" or with "$" or id() or what have you to
> each.

I don't understand what this means. Why would you preprocess the XPath
expressions in this way? What I'm suggesting makes use of perfectly
normal XPath expressions. I'll explain my proposal in more detail.

The evaluation context for XPath expressions is defined as follows [1]:

  "The context consists of:

      * a node (the context node)
      * a pair of non-zero positive integers (the context position and the
        context size)
      * a set of variable bindings
      * a function library
      * the set of namespace declarations in scope for the expression

  The context position is always less than or equal to the context size.

  The variable bindings consist of a mapping from variable names to variable
  values. The value of a variable is an object, which can be of any of the types
  that are possible for the value of an expression, and may also be of
additional
  types not specified here.

  ..."

So, the evaluation context for all XPath expressions already includes
variable bindings. That is independent of XForms--it's just that in
XForms we haven't described how to add variables, so the variable
bindings part of the evaluation context is always empty.

But assume for a moment that we _did_ provide a way to add variable
bindings--then the syntax for getting at a variable is to use the '$'.
[2] In other words, there is no pre-processing required to add the
ability to use $gender--it's already given by XPath, and will be
sitting unused in the XPath evaluators in current XForms processors.

The bit that joins the two together is that I am suggesting that we
already have a technique for adding variables in XForms--what else
would you call a named nodeset?


> Mark argues that the form author would be asked to type the $.  The problem there
> is that the first time they forget the $, it's just like forgetting "../".  It doesn't work and
> they don't know why.

I don't understand how that constitutes an argument. You can't use
Dojo unless you remember to include the libraries...you can't use
GMaps unless you include the script and some CSS...you can't use a
form unless you have a form element...you can't use a computer unless
you turn it on...

My guess though, is that debugging an expression like this:

  <output value="$a * $b" />

is not going to be too difficult; if on first use you accidentally
type in this, you'll see nothing:

  <output value="a * b" />

It's certainly no more difficult to work out what is going on here
than making a mistake in the Web Forms 2.0 equivalent [3]:

  <output name="result" onforminput="value = a.value * b.value">0</output>


> 2) A second problem for the use of variables is that it will create naming conflicts with
> variables that authors want to create when we *do* add the xforms:variable construct
> to XForms.

I've said a few times that I don't see what is added by doing
something like this in XForms:

  <xf:variable id="a" nodeset="y" />

What does that give you over and above the named nodesets that xf:bind
gives you? In other words we already have variables in XForms, we just
haven't made them available in the evaluation context of our XPath
expressions. (And it would be interesting to hear from implementers
whether this would take very long to fix! David? Erik?)


> 3) A third problem with the variable approach is that it breaks at the first sight of a
> grouping.
> Suppose for example that you create an "address block"
>
> <group name="address">
>   <label>Ship to:</label>
>   <input name="name" ...
>   <input name="street" ...
>   <input name="city" ...
>   <input name="region" ...
>   <input name="country" ...
>   <input name="postalcode" ...
> </group>
>
> Nice.

I don' t understand why you think there is hierarchy here? In HForms
this would simply result in a submission of the name/value pairs for
the address. There is nothing that will help us get any hierarchy.

In XForms we have two ways to address data; we can either go to it
directly, using XPath expressions, or we can add a level of
indirection, using bind. The first method allows for hierarchy
(obviously), whilst the second method is a flat space. I am arguing
that since XForms is also a flat space, we should be seriously
considering using the bind mechanism as our 'bridge' between HForms
and XForms.


> Now you want it again because you need a "Bill to" address:
>
> <group name="billto">
>   <label>Bill to:</label>
>   <input name="name" ...
>   <input name="street" ...
>   <input name="city" ...
>   <input name="region" ...
>   <input name="country" ...
>   <input name="postalcode" ...
> </group>
>
> Now, let's look at the identified binds created by this.
>
> Hmmm.  I don't know whether to nest the binds for things like name into the
> address and billto binds,
> but either way I seem to have to create duplicate IDs!

Why are you looking to provide features that we don't currently have
in XForms anyway? If you had the XForms Full equivalent of your
example:

  <group bind="address">
    <label>Ship to:</label>
    <input bind="name" ...
    <input bind="street" ...
    <input bind="city" ...
    <input bind="region" ...
    <input bind="country" ...
    <input bind="postalcode" ...
  </group>
  <group bind="billto">
    <label>Bill to:</label>
    <input bind="name" ...
    <input bind="street" ...
    <input bind="city" ...
    <input bind="region" ...
    <input bind="country" ...
    <input bind="postalcode" ...
 </group>

Then the second set of input controls would be bound to the same nodes
as the first set of input controls--there is no hierarchy with
@bind...it's a 'flat space'.

Now, if you wanted to have hierarchy then you would need to use XML,
and I would think at that point you would switch to using @ref on your
input controls, and not @name or @bind:

  <group ref="address">
    <label>Ship to:</label>
    <input ref="name" ...
    <input ref="street" ...
    <input ref="city" ...
    <input ref="region" ...
    <input ref="country" ...
    <input ref="postalcode" ...
  </group>
  <group ref="billto">
    <label>Bill to:</label>
    <input ref="name" ...
    <input ref="street" ...
    <input ref="city" ...
    <input ref="region" ...
    <input ref="country" ...
    <input ref="postalcode" ...
 </group>


> This is problematic because we need to be able to convert Forms Tiny into
> Canonical XForms.
> It is also problematic because duplicate IDs implies duplicate variables, which
> are not allowed in XPath.

I don't see what that means. In my model @name is (almost) equivalent
to @bind, so they are both referring to the same underlying value--I'm
not suggesting that we create a new binding for each occurrence of
@name, so there won't be any duplicates.


> 4) Notice in problem #3 that I did not even have to touch a repeating construct to
> break the system.

But you didn't break the system. :) And even if you had used a
repeating construct, you'd be limited not by anything to do with this
technique, but by XForms itself; since I am suggesting nothing more
than @name is (roughly) equivalent to @bind, then anything you are
unable to do with @bind, you will of course be unable to do with
@name.


> But the real problem is that we need to be able to solve the repeat problem in
> Forms Tiny.  My prior
> post contained a completely working purchase order written in a proposed variant
> of Forms Tiny.
> In order to make the "identified binds+variables" proposal viable you need to be able
> to show how
> that purchase order form (the simplest of repetitions) can be expressed so that we
> can evaluate
> its authoring ease relative to the direct "name-to-data" proposal and so we can evaluate
> whether
> it transforms into a canonical XForm.

With respect, if we are going to talk about "a repeat problem" we
should at least say what that problem is. Currently it is very badly
posed.

In XForms repeat works across data. However, via a clear definition
about the relationship between the model and the view, we get extra
controls appearing when we add extra data, and they disappear when we
remove data.

By contrast, repeat in Web Forms 2.0 is all about repeating *mark-up*
[4]. This is still very useful--and many Ajax libraries support such a
feature--but it is solely concerned with the view. Of course, there is
no reason why we shouldn't be able to have repeating templates in
XForms that exist only in the view; this would be not unlike switch
and case, which also exist at the level of the view, and have no
reflection in the model. But the key point is that we don't need to
squeeze the all powerful XForms Full repeating data architecture into
XForms Tiny--if someone wants to do repeating *data*, they should
embrace a little more of XForms full, and if they want repeating
mark-up we can give them that with a simple syntax that doesn't need
hierarchical data.


> 5) The X of AJAX is for XML!  Preaching to the converted, I know...

I don't mind...I'm just please to see preaching *from* the converted. :)


> ..., but the attention to AJAX right
> now is based on a property of XForms submission: You can exchange XML with the
> server.
> Given that the "name-to-data" proposal is capable of effortlessly implying structured
> XML...

But it doesn't effortlessly imply structured XML--how do you obtain
the hierarchy? In HForms there is no way to submit XML!


> ...it would be a mistake to adopt another proposal that makes it difficult or
> impossible to let authors scale up smoothly to using the Forms Tiny XML
> data model with XForms submissions.

It would indeed. But this proposal is not "impossible" to scale
up--all I've done is allow this:

  <input bind="sn">
    <label>Surname:</label>
  </input>

to be expressed like this:

  <label for="fc1">Surname:</label>

  <input id="fc1" name="sn" />

I'm actually trying to keep things as consistent as possible in terms
of what HForms represents, and what XForms represents.

Suggesting that @name suddenly becomes an XPath expression seems to me
to do the opposite, and is completely against the spirit of HTML. The
'name' attribute currently 'names the control', and so any solution
that wants to make a bridge to the XForms data model must not 'hijack'
@name, but instead should provide one level of indirection from this
'control name' to some underlying data; I'm suggesting that we already
have a mechanism for indirection in XForms, and that is 'bind'.

By the way, the only reason for adding the ability to _address_
variables is so that authors can also do this:

  <output value="concat('Your name is ', $sn)" />

It keeps them away from the full issues of XPath for a little longer.
(But even without the use of variables, I think that using @name as a
mapping to a bind statement rather than an XPath expression is still
legitimate for the reasons given above.)


> For that matter, we need a system that allows authors to access the Forms Tiny
> data model
> period.  In other words, there has to be a few steps along the way between Forms Tiny
> and
> canonical XForms.  Those steps should include:
>
> a) allowing script authors access to the DOM suggested by the Forms Tiny model

I don't understand...that already exists in XForms. Or are you just
saying that we should ensure that they're in XForms Tiny.


> b) allowing author to take control of the XML instance at a time of their choosing to
> better control
> prepopulation results e.g. via JSP.  In other words, let them specify the instance.

Sure.


> c) allowing author to take control of submission to do instance replacement submissions
> as
> well as switching from urlencoded-post to XML data post

These can be specified by allowing <submission> attributes on <form>.


> d) allow authors to use XForms actions against the data model in a straightforward way
> to
> insert and delete nodes as well as set values.

You can't get more straightforward than what we already have in XForms.


> e) The ultimate in flexibility would be to allow authors the ability to add secondary
> instances
> for temporary variables, and to then add binds or use actions to manipulate that data
> and
> to move data between those instances and the primary instance generated by
> FormsTiny.

XForms Full also could do with a way of addressing a lazily authored
instance, so that's no big deal. My main point is that nothing we need
is specific to XForms Tiny.


> This would be ideal for adding the ability to talk to a SOAP service to a Forms Tiny asset
> without converting it to canonical XForm.
>
> f) Next thing you know the form author has learned everything they need to know to write
> canonical XForms so their next project can start with a schema and a real data model.

Yep.


> To conclude, there is nothing that you state below Mark as an advantage of the "identified
> binds + variables" proposal that is not also an advantage the "name-to-data" proposal.

Doesn't use XPath in @name in HForms. Doesn't require a new evaluation
context mechanism in XForms Full.


> However, the name-to-data proposal has the advantages of  solving all of the problems
> above
> with *no* changes other than a simple attribute for #1.

It may be a simple attribute, but if you step over to the XForms side
of the looking glass for a moment, it seems a very odd addition to the
language. It creates yet another way of resolving the evaluation
context, and it does it by evaluating an XPath expression, which is
itself evaluated in the evaluation context of the nodset on 'bind'.
It's quite a leap.


> binds + variables" proposal has no answers for the above AND requires the addition to
> XForms of features like a bind function or variables that refer to bind nodesets that
> require an
> extensive overhaul of the XForms processing model to fully specify.

I don't think it really affects the XForms processing model.


>  You can make them
> work in limited use cases, but the language falls apart when the features are fully
> considered.

Hopefully it's clear now that this is not the case.

Regards,

Mark

[1] <http://www.w3.org/TR/xpath#section-Introduction>
[2] <http://www.w3.org/TR/xpath#NT-VariableReference>
[3] <http://whatwg.org/specs/web-forms/current-work/#the-output>
[4] <http://whatwg.org/specs/web-forms/current-work/#repetition>

-- 
Mark Birbeck
CEO
x-port.net Ltd.

e: Mark.Birbeck@x-port.net
t: +44 (0) 20 7689 9232
w: http://www.formsPlayer.com/
b: http://internet-apps.blogspot.com/

Download our XForms processor from
http://www.formsPlayer.com/

Received on Thursday, 26 October 2006 21:28:28 UTC