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

Hi Uli,

"Nested model" was a shorthand for saying that we need identifiable model 
*fragments* that can be brought in externally, not just external whole 
models.

Use of XInclude and/or src on bind are two examples of doing just that.

But one question about XInclude:  in the parse XML case, does it allow the 
content being received to be an external general parsed entity?

In other words, can I pull in multiple elements that have no single root 
element?  Or does XML include require that the content be well-formed XML 
in the parse="XML" case?

Reason I ask is that I'd like the include mechanism to be able to pull in 
the SOAP envelope instances and the submission for a web service.  If 
XInclude can't do this, then we'd need some kind of "nested model" wrapper 
element.  Something like "fragment" or "submodel"...

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:
Ulrich Nicolas Lissé <unl@dreamlab.net>
To:
John Boyer/CanWest/IBM@IBMCA
Cc:
Erik Bruchez <ebruchez@orbeon.com>, Forms WG <public-forms@w3.org>, 
public-forms-request@w3.org, mark.birbeck@webbackplane.com
Date:
06/17/2009 07:19 AM
Subject:
Re: [ExternalModel, NestedModel] Why not include with @id, @src and  @ref?



Hi John,

like Nick and Erik I'm in favour of using XInclude for a more or less 
generic inclusion mechanism. I think it is a quite simple Spec, at 
least in W3C terms. It has been implemented a multiple times (in Java 
land) and is gaining usage - it is field test proof. I completely 
agree with Raman's and your advice not to bother with overcomplicated 
W3C Specs which tend to introduce more problems than they solve, but 
IMHO that's not the case with XInclude. Ignoring XInclude and rolling 
our own solution instead would be a serious indication of the NIH 
syndrome ;-)

XInclude provides a compelling feature, which a @src attribute could 
never support: It allows @accept and @accept-language attributes which 
allow for Content Negotiation. Apart from plain file based inclusion I 
think any inclusion mechanism used in XForms should play well in a 
RESTful environment. In this regard we already have  shortcomings with 
xf:instance/@src. Of course you could use a xf:submission to gain fine 
control over request headers and such, but that's too complex and only 
applicable to instances.

Additionally, XInclude cares for XML Namespace, XML Base, and Language 
Fixup and has an easy fallback mechanism. These features might appear 
as an overkill for your use cases, but I think they are essential. 
Maybe we can allow @src virtually everywhere and simply define its 
processing model by means of XInclude, e.g. <xf:bind src="bindings/ 
some-constraints.xml"/> would be processed exactly like <xf:include 
href="bindings/some-constraints.xml"/>. If a form author needs more 
control over inclusion specifics, she/he could switch to XInclude and 
add @accept and so on. Full XInclude support would be optional for 
XForms processors.

However, as you mention the ID conflict issue persists regardless of 
what inclusion mechanism is used. We have to find a solution for this 
anyway.

There's one more point I'd like to stress: Please let us not mix the 
discussions about external and nested models. We desperately need 
external models (or any other XForms components). However, I am 
absolutely not convinced of the nested models idea.

Best,
Uli.

On 16.06.2009, at 19:13, John Boyer wrote:
> 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/
>
>
>
>

--
Ulrich Nicolas Lissé