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

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.
--