<trackbot> Date: 03 October 2012

<scribe> scribe: nvdbleek

load/@show='embed'

John_Boyer: Without a scoping mechanism we aren't going to solve the current limitations
... A number of vendors have worked around the issues
... We have a design time feature for building components
... it is easier to solve the id scoping issues at design time
... Maybe we could just note in the spec the limitations

nvdbleek: We are using the XBL approach allot lately, but other implementers found that approach to complicated

Steven_: An imperfect solution isn't very nice

nvdbleek: I find the current proposal to imperfect for being the standardised way to do sub-forms

Steven_: We always attempted to do the perfect thing
... We could specify that IDs should be consistently renamed

nvdbleek: One of the use cases was to send events from outside the the subform inside the subform

John_Boyer: It could be expensive to do the rewriting at run-time

<John_Boyer> Although some have often struggled with it, my point is that I never struggle with it anymore because the design tool handles subforms, ID rewriting and rewriting of IDREFs to match

John_Boyer: I would be happy if a run-time version of this is added to the spec, but it is going to take a long time to specify, test and validate

Steven_: So does this mean that the user should make sure that the ID's are unique

nvdbleek: We can support the same ID's at different repeat iteration, but we have to specify this.

John_Boyer: The user can't know if there are ID conflicts, because he is getting the contents from somewhere else
... In my opinion it is either don't touch the feature or otherwise do it right

ebruchez: last time we had some exchanges on the mailing, Joern had a strong opinion to keep the solution simple. And don't make it to complicated.

John_Boyer: If you make your id's namespaced by prepending something unique for every form would 'solve' the problem

<ebruchez> http://lists.w3.org/Archives/Public/public-xformsusers/2012Jun/0019.html

<ebruchez> http://lists.w3.org/Archives/Public/public-xformsusers/2012Jun/0018.html

ebruchez: I wanted try to set some things that could be done, without specifying to much
... An implementation could automatically prefix the ID's, another implementation could use a shadow tree. But then you have to specify if and how you could send events inside the subform from outside the subform
... I was also leaning to not doing something half baked
... The baked solution is that the implementation should solve the duplicate IDs

John_Boyer: When you send an event from outside the subform to the inside we should specify what the id for the target attribute should be

<ebruchez> - events from the embedded form should not flow over to the embedding form

<ebruchez> - the embedding form should not be able to address elements of the

<ebruchez> embedded form with simple id references

<ebruchez> - the embedded form should not be able to address elements of the

<ebruchez> embedding form with simple id references

<ebruchez> - the embedding form must be able to dispatch an event to the embedded form

<ebruchez> - the embedded form must be able to dispatch an event to the embedding form

<ebruchez> http://lists.w3.org/Archives/Public/public-xformsusers/2012Jun/0015.html

John_Boyer: We could decide that it isn't possible to not send events across subform boundaries
... What if you have to separate loaded subforms with the same ID inside, how do you know to which subform to target when you send to that ID from the main form?

<John_Boyer> Given a form with two subforms, how can a run-time decide whether X is a reference to the thing with id="X" in subform A or subform B

zakm, mute me

ebruchez: Maybe you shouldn't be able to send events directly inside a subform, but only to the subform, and the controls in the subform should listen to the subform

<John_Boyer> The IDREF X could become A_X or B_X, for example.

ebruchez: this is typically what you do if you are using shadow-trees
... we could also allow prefixing the IDs, but then every implementation should support this

This is scribe.perl Revision: 1.137  of Date: 2012/09/20 20:19:01  
Check for newer version at http://dev.w3.org/cvsweb/~checkout~/2002/scribe/

Guessing input format: RRSAgent_Text_Format (score 1.00)

Succeeded: s/backed/baked/
Found Scribe: nvdbleek
Inferring ScribeNick: nvdbleek
Default Present: nvdbleek, [IPcaller], John_Boyer, ebruchez
Present: nvdbleek [IPcaller] John_Boyer ebruchez Alain Steven
Regrets: Philip
Agenda: http://lists.w3.org/Archives/Public/public-forms/2012Oct/0002.html
Found Date: 03 Oct 2012
Guessing minutes URL: http://www.w3.org/2012/10/03-forms-minutes.html
People with action items: 

WARNING: Input appears to use implicit continuation lines.
You may need the "-implicitContinuations" option.