Re: [ExternalModel, NestedModel] Why not include with @id, @src and @ref?

Hi Erik and Mark,

I realized on the way to work that the context setting issue I had asked 
Mark about is solvable by using src on an *inner* bind, like this

<bind nodeset=".../shipTo"> <bind src="address.constraints.xml"/> </bind>
<bind nodeset=".../billTo"> <bind src="address.constraints.xml"/> </bind>

This is only slightly more verbose than I had originally advocated, where 
I put nodeset and src on the same bind.  It doesn't solve ID conflicts of 
course, so any IDs used in the "address.constraints.xml" would either have 
to be unavailable or somehow rationalized.

Erik, you've indicated that I "exagerated" problems with XInclude, but I'm 
wondering if you could elaborate on why you believe this.  It is hard to 
understand because you then go on to agree with some of the key problems.

I can live with using XInclude as long as someone who knows XInclude can 
boil it down to the portion of the spec that would be required to 
implement in order to meet the technical requirements we need to address 
and as long as we don't have to give up on technical requirements because 
they can't be met.

The ID space problem is tricky.  You propose using a name attribute 
instead.  I see how this avoids ID clashes at the XML level, but isn't it 
trading apples for apples at the author level?  In other words, from the 
author's perspective, call it a name but I then have the potential of name 
clashes across included content.  We'd still have to layer a name 
resolution protocol over top of the included content, regardless of how we 
include it, and that name resolution method would have to be available to 
the instance() function in XPath, not just XForms IDREF attributes like 
@bind and @submission.

Cheers,
John M. Boyer, Ph.D.
STSM, Interactive Documents and Web 2.0 Applications
Chair, W3C Forms Working Group
Workplace, Portal and Collaboration Software
IBM Victoria Software Lab
E-Mail: boyerj@ca.ibm.com 

Blog: http://www.ibm.com/developerworks/blogs/page/JohnBoyer
Blog RSS feed: 
http://www.ibm.com/developerworks/blogs/rss/JohnBoyer?flavor=rssdw





From:
Erik Bruchez <ebruchez@orbeon.com>
To:
Forms WG <public-forms@w3.org>
Date:
06/16/2009 09:09 AM
Subject:
Re: [ExternalModel, NestedModel] Why not include with @id, @src and  @ref?



All,

John: I think you are exagerating the complexity of XInclude below. It 
is in fact quite simple. The feature of it that interests us is 
embedding one infoset within another infoset (parse="xml"). We can 
completely ignore the other side of it (parse="text"). In our 
implementation, we use XInclude on a daily basis. It does address some 
reuse scenarios, although maybe not all the problems John would like 
to cover.

Further, XForms doesn't have to mandate that implementors implement 
XInclude, any more that it mandates that implementors implement XML 
Schema.

This said, whether we can live with simple inclusions a la XInclude is 
a valid question. If we can, there is a HUGE benefit: simplicity.

In term of issues caused by identifiers, I offer the following idea:

XForms has a very strong dependency on id resolution. This causes 
issues due to the fact that ids are expected to uniquely identify 
elements in a document, and therefore to be unique. This means that 
even simple inclusion scenarios can break. Even if XInclude was to 
perform id fixup, then things are still broken because the user of the 
included models might not be able to rely on the presence of 
particular id. Further, you can perform inclusions by other 
mechanisms, such as simple server-side inclusion (in Java, PHP, you 
name it).

I have been thinking for a long time that we need to break this 
dependency on id resolution.

I would propose that we introduce a general use of the @name attribute 
on model elements, including xforms:model, xforms:instance, 
xforms:bind, and xforms:submission. Since we already have the @model 
attribute to identify a model, using a particular reference to a name 
within that context would be unambiguous.

If we were to do this, then plain inclusions as well as inclusions 
with XInclude would not susceptible to id clashes. This would increase 
the value of simple inclusions in XForms, with XInclude or not, 
therefore increasing reuse, and all that for a very low cost.

-Erik

On Jun 16, 2009, at 6:55 AM, John Boyer wrote:

>
> Hi guys,
>
> Nick:
>
> How does XInclude's ID fixup feature in section 4.5.3 account for 
> use of ID's in the parameter of the instance function in an XPath 
> expression?
>
> How does XInclude accommodate providing an alternative XPath context 
> node to included bind elements, as in the example I gave about 
> applying a set of constraints to two different subtrees of data 
> (like a shipTo and billTo address block)?
>
> How does adopting a 20 page XInclude spec benefit us when the 
> mechanism we need to solve all the use cases that have arisen so far 
> can be written in one page and glued directly to our processing 
> model?  I've been all for adopting others specs and hoped for return 
> consideration that simply has not come.  We've spent a huge amount 
> of time dealing with the resultant complexities, at the expense of 
> velocity on XForms features.  This makes me want to do the simplest 
> thing that works for us and let the excellence of our product drive 
> its adoption.
>
> Mark:
>
> What if one of the separations of concern is to write the XForms 
> submissions and instances for the web services that the form will use?
>
> In terms of separation of concerns, why would it be any harder to 
> say <include src="somebinds.xml"/> than to say <bind 
> src="somebinds.xml"/>?
>
> What if the IDs used in one group of binds conflict with those used 
> in another group of binds?  As the repository of forms grows, 
> avoiding ID space conflicts among components becomes increasingly 
> tricky and authors tend to need an automated way of resolving the 
> conflicts.  If we write a feature that does not scale up beyond 
> writing singular forms, then we get limited reusability.
>
> Cheers,
> John M. Boyer, Ph.D.
> STSM, Interactive Documents and Web 2.0 Applications
> Chair, W3C Forms Working Group
> Workplace, Portal and Collaboration Software
> IBM Victoria Software Lab
> E-Mail: boyerj@ca.ibm.com
>
> Blog: http://www.ibm.com/developerworks/blogs/page/JohnBoyer
> Blog RSS feed: 
http://www.ibm.com/developerworks/blogs/rss/JohnBoyer?flavor=rssdw
>
>
>
>
> From:
> Nick Van den Bleeken <Nick_Van_den_Bleeken@inventivegroup.com>
> To:
> Mark Birbeck <mark.birbeck@webbackplane.com>
> Cc:
> John Boyer/CanWest/IBM@IBMCA, "public-forms@w3.org" <public-forms@w3.org 

> >
> Date:
> 06/16/2009 01:23 AM
> Subject:
> RE: [ExternalModel, NestedModel] Why not include with @id, @src 
> and         @ref?
>
>
>
>
> Mark,
>
> I completely agree with you, that a src attribute and one or a 
> couple of extra attributes is much more form author-friendly, and 
> therefore superior, compared to a generic full blown inclusion 
> mechanism from an authors standpoint (certainly because we are/ 
> should focus on the ease of authoring).
>
> I'm just against us inventing a new full blown XML inclusion 
> mechanism if we have the opportunity of re-use an existing spec that 
> does what we need. I've used XInclude in combination with XForms 
> before and it did the job, but I have to agree with you that it 
> doesn't formally defines in markup 'what' you are including (binds, 
> instances, schema's), you have to deduce it from the url, comments 
> or go the actual file to know what exactly you are including. 
> Sometimes it is good to not need to know what exactly you are 
> including but most of the time it isn't an advantage.
>
>
> Regards,
>
> Nick Van den Bleeken
> R&D Manager
>
> Phone: +32 3 821 01 70
> Office Fax: +32 3 821 01 71
> Nick_Van_den_Bleeken@inventivegroup.com
> http://www.inventivegroup.com
>
> > -----Original Message-----
> > From: Mark Birbeck [mailto:mark.birbeck@webbackplane.com]
> > Sent: dinsdag 16 juni 2009 9:53
> > To: Nick Van den Bleeken
> > Cc: John Boyer; public-forms@w3.org
> > Subject: Re: [ExternalModel, NestedModel] Why not include with @id,
> > @src and @ref?
> >
> > Although I don't agree with Nick on the specific XInclude 
> questions, I
> > do agree that we seem to be overcomplicating this.
> >
> > Perhaps there is a use-case for the more subtle forms, but the 
> single
> > use-case that I have been hoping for (for quite a long time) is
> > nothing more complex than being able to factor out parts of a form 
> to
> > a separate document for (a) ease of authoring, and (b) reuse.
> >
> > I think 'ease of authoring' is quite an important issue; with XForms
> > you can have one person design the schemas, another build the form,
> > and yet another write the help and hint text (to be included via 
> @src
> > on instance). But you can't currently separate out the business 
> rules.
> >
> > Anyway, anything beyond this simply extension -- like the current
> > discussion about many forms being able to work together to fill in 
> the
> > same model (if I understand it correctly) -- would be a bonus, but 
> I'm
> > not going to get too excited about it, given that we still don't 
> have
> > the simple version.
> >
> > By the way, I do accept that XInclude would do what I want, but the
> > problem is that it's not very obvious when reading the source, 
> what is
> > being included; taking a more explicit approach is generally much
> > clearer:
> >
> >   <xf:model id="mdlPurchase" schema="schemas/purchase.xsd">
> >     <xf:instance src="purchase.xml" />
> >     <xf:bind src="bindings/address.xml" />
> >   </xf:model>
> >
> > with the 'bind' file containing a set of reusable business rules.
> >
> > Regards,
> >
> > Mark
> >
> > [1] <http://lists.w3.org/Archives/Public/www-forms-
> > editor/2003Feb/0009.html>
> >
> > On Tue, Jun 16, 2009 at 8:00 AM, Nick Van den
> > Bleeken<Nick_Van_den_Bleeken@inventivegroup.com> wrote:
> > > Hi John,
> > >
> > >
> > >
> > > I'm not completely convinced why XInclude isn't solving the 
> problems
> > you
> > > describe in your e-mail. XInclude does fixup IDREF or IDREFS as
> > described in
> > > section 4.5.3 references Property Fixup[1].
> > >
> > >
> > >
> > > I'm also a bit worried of us creating an include element in our
> > namespace
> > > that is similar to another include element (in another namespace)
> >  defined
> > > in another spec that does nothing else then defining an inclusion
> > mechanism.
> > > So I think if we don't want to use XInclude we have the have a 
> 'damn
> > good
> > > reason' (it is a bit hypocrite wanting other specs to re-use 
> (parts)
> > of our
> > > spec, and us going to re-invent things that are defined in other
> > specs).
> > >
> > >
> > >
> > > Regards,
> > >
> > >
> > >
> > > Nick Van den Bleeken
> > >
> > > R&D Manager
> > >
> > >
> > >
> > > Phone: +32 3 821 01 70
> > >
> > > Office Fax: +32 3 821 01 71
> > >
> > > Nick_Van_den_Bleeken@inventivegroup.com
> > >
> > > http://www.inventivegroup.com
> > >
> > >
> > >
> > > 1: http://www.w3.org/TR/xinclude/#references-property
> > >
> > >
> > >
> > >
> > >
> > > From: public-forms-request@w3.org [mailto:public-forms-
> > request@w3.org] On
> > > Behalf Of John Boyer
> > > Sent: dinsdag 16 juni 2009 1:13
> > > To: public-forms@w3.org
> > > Subject: [ExternalModel, NestedModel] Why not include with @id, 
> @src
> > and
> > > @ref?
> > >
> > >
> > >
> > > Just to keep the discussion going here on external models and 
> nested
> > models,
> > > I've said previously that I did not think having src on the outer
> > model
> > > element was sufficient for most reasonable use cases (i.e. 
> anything
> > but a
> > > small model that doesn't make much use of constraints).
> > >
> > > In [1], I provided a significant elaboration of all the types of
> > things I
> > > was trying to achieve, such as consuming constraint bundles 
> multiple
> > times
> > > by context and consuming XForms-based web service definitions.
> > >
> > > [1] http://lists.w3.org/Archives/Public/public-
> > forms/2009Jun/0042.html
> > >
> > > Previously, Erik suggested using XInclude, which I think won't 
> get to
> > my
> > > context-based consumption case, and Raman also advocated not
> > constraining
> > > ourselves to external specifications if they don't do exactly 
> what we
> > want
> > > and/or add too much complexity.
> > >
> > > It seems reasonable, then, to ask whether we just need a simple
> > <include>
> > > element with semantics that we define as follows:
> > >
> > > 1) Using element include ensures no confusion with xforms 
> semantics
> > on
> > > models; there's just one outer model.
> > >
> > > 2) @id on include provides a referencing conduit into the id 
> space of
> > the
> > > included content.
> > > i) References within included content could work as normal, e.g.
> > > instance("someID")/blah
> > > ii) References from included content out to the inclusion stack 
> out
> > to the
> > > outermost model could also work without further qualification
> > > iii) References into include content from the outside could add a
> > parameter
> > > to instance(), e.g. instance("someInclude", "someID").
> > > iv) The instance function can have as many params as needed to 
> handle
> > > inclusion nesting (i.e. drilling *into* the inclusion stack).
> > >
> > > 3) @src attribute pulls content into the model from the external 
> URI
> > in the
> > > ID subspace
> > >
> > > 4) If given, @ref attribute provides context node for included
> > content,
> > > overriding root element of first instance included in containing
> > model.
> > >
> > > The simple case Steven wanted looks like this:
> > >
> > > <model>
> > >     <include src="model.xml"/>
> > > </model>
> > >
> > > so it is still achievable with minimal overhead.  Given the rules
> > above, all
> > > the use cases I have on my list in [1] are covered, too.
> > >
> > > Can anyone think of others?  Any reason not to proceed with this
> > idea?
> > >
> > > John M. Boyer, Ph.D.
> > > STSM, Interactive Documents and Web 2.0 Applications
> > > Chair, W3C Forms Working Group
> > > Workplace, Portal and Collaboration Software
> > > IBM Victoria Software Lab
> > > E-Mail: boyerj@ca.ibm.com
> > >
> > > Blog: http://www.ibm.com/developerworks/blogs/page/JohnBoyer
> > > Blog RSS feed:
> > > http://www.ibm.com/developerworks/blogs/rss/JohnBoyer?flavor=rssdw
> > >
> > > --
> > > This message has been scanned for viruses and
> > > dangerous content, and is believed to be clean.
> > > --
> > >
> > > ________________________________
> > > Inventive Designers' Email Disclaimer:
> > > http://www.inventivedesigners.com/email-disclaimer
> > >
> > > --
> > > This message has been scanned for viruses and
> > > dangerous content, and is believed to be clean.
> > > --
> > >
> >
> >
> >
> > --
> > Mark Birbeck, webBackplane
> >
> > mark.birbeck@webBackplane.com
> >
> > http://webBackplane.com/mark-birbeck
> >
> > webBackplane is a trading name of Backplane Ltd. (company number
> > 05972288, registered office: 2nd Floor, 69/85 Tabernacle Street,
> > London, EC2A 4RR)
> >
> > --
> > This message has been scanned for viruses and
> > dangerous content by MailScanner, and is
> > believed to be clean.
> > --
> >
>
>
> Inventive Designers' Email Disclaimer:
> http://www.inventivedesigners.com/email-disclaimer
>
> -- 
> This message has been scanned for viruses and
> dangerous content by MailScanner, and is
> believed to be clean.
> --
>
>
>
>

--
Orbeon Forms - Web Forms for the Enterprise Done the Right Way
http://www.orbeon.com/