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

Hi John,

thanks for the clarification on "nested" models.

And yes, XInclude can include multiple elements [1].

Best,
Uli.

[1] http://www.w3.org/TR/xinclude/#multiple-nodes

On 17.06.2009, at 16:26, John Boyer wrote:
> 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é
>
>
>
>
>
>
>

--
Ulrich Nicolas Lissé

Received on Wednesday, 17 June 2009 14:38:19 UTC