Re: repeats


please. I think this was a good discussion started
from Jason, and I see no use in bringing a negative
mood into feedback from authors back to WG. XForms
1.1 is not fully finalised yet, and it is possible
to add errata to XForms 1.0 just in case. I'm
sure the WG is listening to Jason.

On a more philosophical note, if this feedback loop
back from authors and implementors to the WG is
emotionally overloaded and therefore non efficient,
the scenarios you describe would perhaps more
likely happen than the other way around, which
I guess is not your intention.

All the best,

- Sebastian

Francisco Monteiro schrieb:
> As an author of a XForms implementation I am getting more confused every
> day, all this complexion in design which should be simple brings me to a
> comparison of XLink and we all know where XLink is used in anger (XBRL
> )which is even more complicated than what it should really be!
> Perhaps it's time to pack up
> Kind Regards
> Francisco
> facileXForms - Really AJAX at heart
> -----Original Message-----
> From: [] On Behalf
> Of Jason
> Sent: 03 November 2006 12:37
> To: www-forms
> Subject: Re: repeats 
> ok - so with the new draft and xforms 1.0 I now have to load an instance and
> a matching prototype instead of the original idea of using the initial
> instance as the prototype.
> in every practical xform I have made I have always ended up setting my
> instance as an empty prototype anyway, then I either remove all the
> offending elements in the xforms-ready event handler, or load new data from
> somewhere.
> why is the 1.1 notion any better than this? and if there is a froced
> prototype (and there is) then why not label it as such, then you could
> re-automate activity like the original insert idea without the xform author
> needing to specify the default behaviour?
> I was hoping that xforms was moving more toward a more free idea with
> respect to managing the xml model, with the bind  elements representing the
> effective interface between model and view. more and more I find myself
> required to use xpath instead of bind in many view attributes just because
> they dont accept a bind or because I cant include the xpath 
> functions to get things working in combination with binds.    I was 
> hoping to be able to effectively traverse unknown xml structures and create
> trees dynamically etc. unfortunately this seems not to be the current
> direction.
> where would be the harm in restoring the older notion of the original
> instance data operating as the default prototype? the new context and origin
> options would not be effected and could be left in place for those that
> choose to use them when they are actually needed
> Jason.

Received on Friday, 3 November 2006 17:49:27 UTC