See also: IRC log
<wiecha> http://lists.w3.org/Archives/Public/public-forms/2010Mar/att-0024/index-diff.html
<Steven_> [Leigh scribing offline]
<nick> There is a big difference between the import and instance use case, I think there is a use case for the override of instances
<scribe> Scribe: Erik
<klotz> http://lists.w3.org/Archives/Public/public-forms/2010Mar/0035.html
<scribe> Scribenick: ebruchez
<klotz> That is the morning minutes.
Leigh: charter says we need to do a note on XForms for HTML. My proposal: document what implementations are already doing.
Charlie: What happens with the attributes spec?
Steven: That was attempt to bridge w/ HTML ppl and that failed. So there is no point anymore.
Charlie: Asking because I found ppl interested in it.
Leigh: My story is we document, and XForms for
HTML/A is a separate document.
... So 2 docs: document current stuff under title XForms for HTML. And
separate doc for attributes version.
... "XForms for HTML" should describes just that, XForms for HTML.
... It will continue to be a rec track doc, and then we can still publish it
as a Note.
Charlie: I don't plan to work myself on the attributes version.
Leigh: We could do both docs as rec track
docs.
... What are the goals for "XForms for HTML"?
Steven: Validation + support models in the body.
<klotz> Validation, documentation
Leigh: It's an architectural choice: Ubiquity supports that, e.g. XSLTForms doesn't.
Erik: Shouldn
'
t such as spec say something about placement of models?
Leigh, Steven: Yes.
Leigh: Styling is a big one too.
Charlie: What's the issue?
Leigh: In Mozilla, CSS syntax w/ xf|* etc. Some implementations just use special class names.
Erik: We decided on class names a long time ago, but it's not in a spec.
Leigh: Transforming implementations, e.g. XSLTForms, insert stuff between elements. So some CSS won't work exactly as intended.
Steven: You could have some base CSS what works with most implementations.
Leigh: We are pretty weak on CSS already, would be nice to say more.
<klotz> Scribnick: klotz
<klotz> Erik: <xf:input><xf:label>...</xf:label>...
<klotz> Erik: What does a transforming impl produce? <label>...</label><input>... loses the nesting. If you want the nesting you do something different.
<klotz> Erik:<span class="xf-input"><label class="xf-label">...</label><input ...></span> with classes
Leigh: We should have goals. E.g. for improved
interoperability and author facility.
... Also, what things are not going to work: xf:submission[@replace = 'all']
not handling events afterwards, or breaking the back button.
Erik: There was a shift from XForms as part of the browser to XForms implemented in HTML/JavaScript etc.
Leigh: That's why we need a new spec to address
those things.
... Including some problematic controls, like upload and range.
... Different schemas: for best author practice, and for conformance
Charlie: Is this only related to XForms/HTML, or a general XForms thing?
Erik: HTML and XHTML are both serialization of an information set, you could apply schema to HTML.
Leigh: Oxygen etc. have tools.
Charlie: Is DTD compatibility in scope?
Steven: DTD has issues w/ e.g. inline instances.
Charlie: Isn't this XForms for HTML, not XForms
for XHTML.
... Should consider the title: is it for HTML or XHTML?
Erik: For us there are not big difference between HTML and XHTML.
Leigh: ...
<klotz> Leigh: Namespaces in HTML are a big red flag to many people and we shouldn't try to claim that.
Steven: Some say that since IE 9 will support XHTML, "distributed extensibility" is no longer an issue.
Leigh: I'd rather not invent new stuff here, just
document. CSS is a little more tricky.
... So in short: 1. Draw CSS to the center 2. Express limitations, and 3.
Schema.
<klotz> Two schemas: one for authors with recommended practices and one for implementors with minimal compliance.
<klotz> Also I'd like to note that we expect DOM APIs and WebApps to provide APIs to reduce limitations in future.
Steven: Erik, do you rewrite CSS as well?
Erik: No, we assume that the CSS author knows the
resulting HTML (use Firebug).
... Seems everybody agrees on those goals.
Leigh: SGML-based HTML is a non-goal.
Charlie: Would be nice later to have something about XForms within HTML (e.g. HTML 6).
Leigh: This is for the future, when the dust
settles on HTML 5.
... First decision: existing document and titles.
<klotz> Leigh: The shortname is xforms-for-html
Steven: Easiest way should be to just put a clarification of the title.
<Steven> and point to the HTML Mime types document for tips on serving to HTML UAs
<Steven> http://www.w3.org/TR/xhtml-media-types/
Charlie: "XForms/A" has yet unknown title, will have content of current "XForms for HTML", and move somewhere else. Current document "XForms for HTML" will have new content and have explanation re. HTML vs. XHTML.
<Steven> phoning in
Leigh: (Summarizes.)
<Steven> http://www.w3.org/TR/XForms-for-HTML/
John: Reason for XHTML only?
Leigh: We don't want to be embroiled in the
HTML/XHTML discussion.
... Theory is to only describe XHTML in the spec, and leave HTML up to
implementors who are free to transform one way or the other.
Steven: Proposal: this documents how ppl are currently serving XHTML+XForms docs to legacy user agents. Docs are XHTML+XForms, but they are served to HTML user agents.
John: It doesn't seem that besides XForms
elements, well-formedness is needed for HTML content.
... You can still use XForms markup within HTML.
Leigh: It's not necessarily interoperable. Some implementations don't support XForms within HTML, so is not current practice.
John: Apps in Ubiquity work better in HTML, XHTML actually harder for Ubiquity.
Leigh: All other implementations are using XHTML.
John: Doc could say that implementations may use the tags in HTML.
Steven: There is a way to serve XForms+XHTML to HTML user agents that will work.
John: We support non-well-formed XHTML.
Leigh: I would really like to try to stay away from the HTML/XHTML debate.
<Steven> really he said "the extensibility debate"
John: Only downside would be that I can't say that we are "XForms for XHTML"-compliant if we produce HTML+XForms.
Leigh: Right.
... Q. re XForms/A: who is going to be the editor?
John: In the short term, we need a different editor.
Leigh: We just move it and leave John as editor.
“There are only two hard problems in Computer Science: cache invalidation and naming things.”
Leigh: "XForms Attributes for HTML"
<klotz> that gives us X4H, XA4H.
RESOLUTION: The current "XForms for HTML" document is renamed to "XForms attributes for HTML".
<klotz> xf
<klotz> xmlns:xf="http://www.w3.org/2002/xforms"
John: Proposing "xa" as namespace prefix. Same namespace.
<scribe> ACTION: Leigh Klotz to document "XForms for HTML" goals for group agreement. [recorded in http://www.w3.org/2010/03/25-forms-minutes.html#action01]
<trackbot> Created ACTION-610 - Klotz to document "XForms for HTML" goals for group agreement. [on Leigh Klotz, Jr. - due 2010-04-01].
<wiecha> http://st85meetings.lotus.com/stmeetings/room/wiecha@us.ibm.com/public
<klotz> http://twitter.com/AlainCouthures/status/8514096737
<klotz> http://en.wikipedia.org/w/api.php?action=opensearch&format=json&search=xforms
<klotz> ["xforms",["XForms","XForms (toolkit)","XForms (disambiguation)"]]
<nick> PicoForms version of the JSON: <json type="array">xforms</json><json type="array" type="array">XForms</json><js
<nick> on type="array">XForms (toolkit)</json><json type="array">XForms (disambiguation
<nick> )</json>
<klotz> http://kuberam.ro/
<klotz> <xf:xslt xmlDoc="instance('instance2')/pac" xslDoc="/webApps/apps/sitKubera/examples/xslt_action/test_xslt_action.xsl" target="instance('instance1')/v1" parameters="instance('instance2')/parameters"/>
<nick> XSLT transform with an XPath function : http://www.saxonica.com/documentation/extensions/functions/transform.html
<xf:replace target="instance('instance2')/pac" origin="instance('instance1')/v1"/>
<Steven> Leigh: An interesting space to watch, since we're seeing people adding extension functions to other people's XForms implementations
<klotz> those are the four demos of exsltforms.
<scribe> Scribe: Erik
<scribe> Scribenick: ebruchez
<Steeeven> Steeeven
John: Compound document/archival format is the better solution. At this time we use @src only. And maintaining a single XML document is harder and harder to maintain. So we go more towards the archival format and the use of the @src attribute. So importing model into a single infoset is of less value and a single attribute would be better. @resource attribute use is not on the rise.
Charlie: I can do a new pass on the text removing @resource and focus on the merge case.
John: Then there are other questions, like ids.
John: Does the entire content of referenced resource get imported? Attributes, binds, etc. get merged.
<klotz> http://www.google.com/webhp?q=import+vs+include
John: Any room for conflicts?
Charlie: Id conflicts.
John: Seems easier to be in situation where imported model and importing model both have same constraint.
<John_Boyer> we should support imported model and importing model both expressing a constraint
Erik: There doesn't seem to be a fundamental issue supporting this: do AND or OR.
Charlie: @calculate could be harder.
... Could there be a question of priority?
John: If sby says node is readonly, then it
should be readonly.
... Especially if we say definitions are merged in. Behavior should be
identical.
Leigh: I did a graph/table showing all the combinations: to be complete, you would need to specify how things combine.
John: Is there a default combination setting?
Leigh: Default right now is "disallow".
John: I was proposing to change that default.
Leigh: I woud propose to make this explicit.
John: Does import get anything over includes?
<John_Boyer> I think model src needs to have better combinators by default and needs to solve some ID problems
Leigh: No, we need to solve the underlying tough issues re. binds merging.
Erik: Validity seems an obvious AND.
John: Right. ...
<John_Boyer> already do it on type+required+constraint
Leigh: In 2002, we said we would look into it for 2.0.
<John_Boyer> which we could maybe reinterpret as one point 2.0
John: Without explicit combinations, I think we have a pretty good solution already.
Leigh: We should look into whether override is the default.
John: No, AND is the natural default.
<John_Boyer> for constraint
Leigh: What about required?
Erik: It's a validity constraint too.
John: And type as well.
... I can already write constraints that never pass, e.g. < 0 and > 0 in
a single constraint.
Erik: required has 2 aspects: data validation & UI.
Leigh: Required goes the other way then.
John: It's an OR on the attribute value, but an AND for the resulting constraint.
Erik: By default, node is readwrite, optional, relevant, and valid.
John: Try the reasonable defaults first, then add explicit combinators if we find out that we need them.
Erik: Would be nice to see use case for non-defaults.
Leigh: Was just saying we need to think about the
potential issues and make sure they are solved, otherwise it's no better than
XInclude.
... I can be convinced that the solution is ok.
John: We already say right now that all types must apply.
Erik: @calculate is tricky. Should probably just be "disallow".
John: We have AND, OR, and "disallow".
Leigh: Also "replace" is possible.
... In RELAX NG, include supports nested schema stuff, which overrides
imported definitions.
Erik: A bit different since in RNG, overrides imported definitions. Here, we have the definitions in the importing model.
John: What about document security?
Erik: If you import, you trust what you are importing.
John: In CDF, there were lots of discussion on security.
Erik: You import submissions, binds, that may
affect instances in importing model. I think you are assuming trust.
... Diff w/ XInclude is we can better import /*/(xforms:*, @schema) while
XInclude requires schemes that nobody implements to do that.
John: And recursion.
... Is it necessary to have separate syntax then?
Leigh: If all we are getting is same as XInclude
behavior, and no value over that, then we should question what we are doing.
... Also, import vs. include.
... For now, it seems to me we are doing include, the simple stuff.
... Lots of stuff that could be done w/ import.
Erik: We don't know what import would do.
John: Id adjustment.
Erik: Other idea was using @name instead of
@id.
... Scenario w/ @name works when referencing model content from the UI because
we already have scoping by model.
<John_Boyer> seems the import element itself needs to say the name that will be used to refer to things in the imported content
John: I need to say <import name="y">.
... scenario of address model, with ship-to and bill-to.
Erik: Better solved w/ XBL and local models.
John: Just an example where you need to control the name.
Erik: Can we work off a real use case?
Charlie: Started with Steven's very simple use case: plain include.
John: So would be illegal to import same resource twice.
<klotz> http://xformstest.org/klotz/2010/03/reception/test1.xml
Erik: We have no experience on this.
Charlie: Think that we should have implementations to base this feature on, not design it here.
Leigh: So a simple include mechanism?
Erik: xf:include
John: Seems valuable to be able to break off stuff to manage complexity.
http://www.w3.org/TR/xslt20/#include
John: Does the schema allow even putting xi:include in the model?
Leigh: Schema is not really relevant here.
... Do like Erik, do your own stuff ;)
Erik: We use XInclude but it has limitations.
Leigh: Why not at the XFDL level?
John: At XForms level would be more future proof.
Leigh: We don't have enough implementation
experience, just Erik and XInclude and he has a list of things he is not happy
with that solution. Who else?
... I would like to see xxf:include in your implementation first.
... People thinking about how nice it would be to have a feature doesn't mean
we are ready to standardize it.
Steven: How is that different from the initial XForm spec?
Leigh: That was a very long time ago.
John: Import/include is not unique to XForms.
<scribe> ACTION: Charlie to remove @resource attribute from external models draft. [recorded in http://www.w3.org/2010/03/25-forms-minutes.html#action02]
<trackbot> Sorry, couldn't find user - Charlie
<John_Boyer> Default combinators (rather than disallow) for MIPs other than calculate
<John_Boyer> type - logical AND
<John_Boyer> constraint - logical AND
<John_Boyer> required - logical OR
<John_Boyer> readonly -logical OR
<John_Boyer> relevant - logical AND
Erik: I suggest XOR for p3ptype.
<John_Boyer> calculate combinator is "disallow"
<John_Boyer> p3ptype combinator is "disallow" (or disallow unless identical)
PROPOSED RESOLUTION: For XForms 1.2, we relax the constraint that only one MIP can apply to a given node. Depending on MIP: type: logical AND; constraint: logical AND; required: logical OR; readonly: logical OR; relevant: logical AND; calculate: "disallow"; p3ptype: "disallow".
RESOLUTION: For XForms 1.2, we relax the constraint that only one MIP can apply to a given node. Depending on MIP: type: logical AND; constraint: logical AND; required: logical OR; readonly: logical OR; relevant: logical AND; calculate: "disallow"; p3ptype: "disallow".
John: If p3ptype is deprecated, we don't even need to test for it anymore.
<klotz> www.zurich.ibm.com/~mts/.../AsKS_03-P3PPracticalExperiences-submit.pdf
<klotz> http://lmgtfy.com/?q=p3p+type+useful+or+not
http://www.zurich.ibm.com/~mts/bibliography/AsKS_03-P3PPracticalExperiences-submit.pdf
PROPOSED RESOLUTION: We deprecate p3ptype in XForms 1.2.
RESOLUTION: We deprecate p3ptype in XForms 1.2.
<klotz> <note>In this version, p3ptype is deprecated</note>
Leigh: We don't have an XForms 1.2 document to put new features in, right?
Erik: We tend to do the first pass on the wiki.
<klotz> OR take old features out.
Steven: I think we should modularize.
Erik: It will take too much manpower and we don't have it.
John: We can start with a thin spec for now.
http://www.w3.org/MarkUp/Forms/wiki/Category:XForms12
<klotz> http://www.w3.org/MarkUp/Forms/wiki/MIPS
Current spec says: "It is an error to attempt to set a model item property twice on the same node (see 4.3.1 The xforms-rebuild Event for details)."
"If a node already contains a model item property of the same name due to the processing of prior bind elements, then XForms processing for the containing document halts with an exception (4.5.1 The xforms-binding-exception Event)."
<nick> http://www.w3.org/TR/xpath-functions/#func-iri-to-uri
<scribe> ACTION: Erik and John to report on use cases and experience on XInclude and form parts as feedback to group. [recorded in http://www.w3.org/2010/03/25-forms-minutes.html#action03]
<trackbot> Created ACTION-611 - And John to report on use cases and experience on XInclude and form parts as feedback to group. [on Erik Bruchez - due 2010-04-01].
This is scribe.perl Revision: 1.135 of Date: 2009/03/02 03:52:20 Check for newer version at http://dev.w3.org/cvsweb/~checkout~/2002/scribe/ Guessing input format: RRSAgent_Text_Format (score 1.00) Succeeded: s/HTML only/XHTML only/ Succeeded: s/formed HTML/formed XHTML/ Succeeded: s/attributes/Attributes/ Succeeded: s/Doest/Does/ Found Scribe: Erik Found ScribeNick: ebruchez Found Scribe: Erik Found ScribeNick: ebruchez WARNING: Replacing list of attendees. Old list: John_Boyer Erik Charlie Steven Nick Leigh New list: [IBMCambridge] John_Boyer Default Present: [IBMCambridge], John_Boyer Present: [IBMCambridge] John_Boyer WARNING: Fewer than 3 people found for Present list! Agenda: http://www.w3.org/MarkUp/Forms/wiki/FtF_2010_03_24_Agenda Got date from IRC log name: 25 Mar 2010 Guessing minutes URL: http://www.w3.org/2010/03/25-forms-minutes.html People with action items: charlie erik john klotz leigh WARNING: Input appears to use implicit continuation lines. You may need the "-implicitContinuations" option.[End of scribe.perl diagnostic output]