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

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<mailto:Nick_Van_den_Bleeken@inventivegroup.com>
http://www.inventivegroup.com<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 by MailScanner, and is
believed to be clean.
--