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)

Received on Tuesday, 16 June 2009 07:53:27 UTC