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

Hi Mark,

In the mail below, you mentioned that if an <include> element were used, 
then the ID would have to be in the included content rather than the host 
document.

I think you may not have noticed the subject line and subsequent content 
in which I explained that such an include element would need an id 
attribute so that the ID would be in the host document.

So I think we do agree on that point.

However, the reason I advocated for an element name other than model, such 
as include, is that I didn't want to run afoul of the fact that xforms 
models don't talk to each other.  By putting includes inside of a model, 
it is clear that they are contributing to that model.

Of course, we could talk about how we might relax that condition instead, 
but it looks to be harder to do that, due to the @model attribute for 
example, than to use an inclusion mechanism of some kind.

But either way, I think that you may have skipped the part of my prior 
email in which I talked about not just how you would activate a behavior 
in the model and register for success/failure events on that model, but 
also how to then extract meaningful information out of that model when the 
successful results were in.  The results from the web service have to 
travel from the web service model to the consuming model that listens for 
the successful result. 

It should be clear that there is a missing piece of functionality.  In the 
case of the <include> mechanism, I proposed we could solve it using some 
kind of ID blending so that the internal content of the included submodel 
could be accessed by setvalue/@value and related constructions.  In your 
alternative case, we would need the ability to define the ability for the 
included model to add context info to custom events.

Either approach works for me, as long as we can do the whole job.

Finally, I think you didn't actually answer the question I asked, which 
was what do you do when you include some ID-bearing content twice, 
regardless of how you spell the inclusion mechanism?  (And to Nick's 
point, if ID were changed to name, then we still have ambiguous name 
problems to handle)

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:
Mark Birbeck <mark.birbeck@webbackplane.com>
To:
John Boyer/CanWest/IBM@IBMCA
Cc:
Nick Van den Bleeken <Nick_Van_den_Bleeken@inventivegroup.com>, 
"public-forms@w3.org" <public-forms@w3.org>
Date:
06/16/2009 11:17 AM
Subject:
Re: [ExternalModel, NestedModel] Why not include with @id, @src and @ref?



Hi John,

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

Right.

But in the use-cases I've been seeing, the idea is to keep the model
entirely encapsulated.

For example, imagine you have a model that logs in to a system like
Twitter. It contains all of the instances required to handle the
user-name and password, and it also has all of the submissions to do
the login. It is activated by firing an event at the model, and it
reports success or failure by firing an event back.

Now, the nice thing about this:

   <model id="mdl-twitter-login" src="login-to-twitter.xml" />

is that the ID of the model is set in the host document, not the
imported document. This means that the host document can initiate the
login like this:

  <dispatch target="mld-twitter-login' event="do-login" />

and can register for the success and failure events, like this:

  <message ev:event="login-failed" observer="mdl-twitter-login">
    Failed to login to Twitter!
  </message>

and so on.

If you do this:

  <include src="login-to-twitter.xml" />

then the model ID would have to be hard-coded inside the included 
document.

Note that for me the key notion here is the idea of the model being
encapsulated. We have quite a lot of these kinds of models that fire
events out to notify the host of status, and listen for events to be
told when to do whatever it is that they do. These events are like
public interfaces, but in most cases we treat the internal interfaces
like private class members -- they are not available to the host
document -- which is why I'm not that bothered about the ID fix-up
issue.

I should just say though, that I'm quite happy with XInclude too, and
agree with Erik that for many developers it's already being used to
good effectl.

All I've been imagining is the use of @src as a little bit of
sugar-coating on XInclude; pretty much the same functionality, but
performing an additional step which is to add the attributes from the
host document (like @id, @schema, @functions, etc.).

But as I said, I'm not a fan of the more elaborate 'fixing up'
approach, because I don't think it moves us to a different realm (more
like template processing, rather than simple document importing).

Regards,

Mark

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