Forms F2F Cannes Virtual Day 1 October 15, 2008

* Present

John Boyer, IBM
Charlie Wiecha, IBM
Leigh Klotz, Xerox
Nick van den Bleeken, Inventive Designers
Steven Pemberton, CWI/W3C
Uli Lissé, DreamLabs
Roger Pérez, SATEC

* Agenda

* Break

* Partial Minutes

These are partial minutes; minutes before this point are at

* Data Layer

John Boyer: Leigh, what was your point before the break?
Leigh Klotz: The data island module should either define a namespace and define functions there and then then XPath functions module should import them, or the XPath functions module could define the namespace and the XPath functions module defines them. Someone higher up can decide to export that namespace's function in another namespace or in the non-namespace.
John Boyer: The XPath 1.0 spec refers to qnames. It doesn't say that added functions have to be prefixed.
Leigh Klotz: Or we could have an XPath function module that defines XPath interfaces to the IDL.
John Boyer: The XPath functions module needs to be first so it can be used in the data island module so we can define instance() and id().
Leigh Klotz: Move instance() and id() into the XPath functions module and make sure they're implementable.
John Boyer: It would have to add to a namespace defined outside the data layer.
Leigh Klotz: Why?
John Boyer: Otherwise it's not useful.
Steven Pemberton: In RDFa, we talk about vocabularies; a vocabulary is identified by a URL.
Leigh Klotz: Is it one URL for the data island module, one for the data layer functions, or one for the XForms functions? We don't have an answer me that.
Steven Pemberton: Does it make a difference either way?
Leigh Klotz: Not really.
Steven Pemberton: For RDFa, we defined an RDFa vocabulary and we can add to it in the future. The WAI are adding stuff to it for the role module. As long as there's no clash, it doesn't matter.
Leigh Klotz: In that sense we should only have one.
Steven Pemberton: Call it a vocabulary instead of a namespace.
Leigh Klotz: I don't care about the namespace or vocabulary. My point is that the data island module ought not define the XPath interface to data islands.
John Boyer: We can have a top-level XPath library that defines an Vocabulary URI for extension functions and define the data layer functions there. We can define data integrity, date and time, etc. in the top-level library.
Leigh Klotz: Or have only the vocabulary defined in the top-level library and define the Data Layer XPath Functions in the namespace. That would be the XPath interface to data islands; tomorrow we could define a JavaScript interface to data islands.
John Boyer: How about "Specifications for functions"
Leigh Klotz: How about "Specifications for logic layer"
John Boyer: These are XPath data layer functions, not logic functions.
Leigh Klotz: I'm willing to admit to mutual mystification and move on.

* XPath Functions

John Boyer: We decided we could take up as future work the goal of adding our functions not as XPath. On the other hand we may find after several iterations we're able to generalize. So at least right now, the data layer has a data island module, with instance() and id() added to the extension functions identified by a vocabulary URI. I don't know why we need to say a vocabulary URI so much as an extension function, because XPath itself allows it.
Charlie Wiecha: This is a way to name that library.
John Boyer: Or just the XPath Function Library.
Charlie Wiecha: But which one? This gives us a URI to name that library.
John Boyer: "Please add instance() to this uri" or "Please add instance() to the XPath functions library."
Steven Pemberton: That's fine. I thought there was some issue about namespaces and namespace-prefixed function names.
John Boyer: I agree; I just think we shouldn't bother to introduce a URI.
Leigh Klotz: XPath 2.0 prefixes function names and XPath 1.0 arguably does (we've been chided for both).
John Boyer: In XPath 2.0 it would have to be qualified, but that's orthogonal to whether the module adds the function to the library or not.
Leigh Klotz: exslt does this.
John Boyer: We have a raft of functions that aren't namespace qualified.
Leigh Klotz: So you have a module that says the following six (or one) namespaces are hereby available unprefixed.
John Boyer: That's the argument for the vocabulary URI.
Leigh Klotz: I don't see a reason to do that. Just use namespaces. People who can't abide namespaces can't abide XPath anway.
John Boyer: The way we do it now is that. What would the spec say?
Leigh Klotz: It would just say "All functions in namespace are hereby available without prefix."
John Boyer: Can't we do that in the same module that defines the vocabulary URI?
Leigh Klotz: Possibly. If we say that it's optional to make them available without prefix.
John Boyer: "Define that a host language can optionally import the extension function collection into the XPath function library as NCName functions." And one URI refers to the entire collection and that's different from the URI that's used for the whole collection.
John Boyer: Anyone can define themselves into this URI by associateing themselves with that URI that's part of the magic useful-without-uri.
Leigh Klotz: Can this framework accomodate namespace-qualified ones exlst style?
John Boyer: Why not?
John Boyer: The data integrity functions can define themselves in a URI and are also part of the extension functions collection.
Leigh Klotz: It's the same mechanism, just top-down vs. bottom-up. I prefer top down because the one spec is a point for resolving namespace conflicts, which can't be resolved in the individual specs if they add themselves to a global URI.
John Boyer: But we don't have to rev one module every time we add another.
Leigh Klotz: Or we can rev one module to add other modules.

John Boyer: Here in the wiki, we have four modules that can define their own URI and also declare they're part of an extension function library declared by URI. The host language can optionally import that collection without using the namespaces.
Leigh Klotz: I'd say that you combine bullet points 1 and 2 and combines them.
John Boyer: It's like the proposal to modularize and have things add themselves to name collections.
Leigh Klotz: But the XPath modules are useful independently and the module would roll them up into XForms 1.2.
John Boyer: But that's backwards.
Leigh Klotz: I guess I can live with your proposal.

Charlie Wiecha: So do we add them to their own URI?
John Boyer: There would be a data island module and it would have its own URI and add itself to the global URI.
Charlie Wiecha: Do we add it to its own module for data functions or do we just annotate the existing module?
John Boyer: I see. Same thing would happen with the context, I presume.

Charlie Wiecha: ...
John Boyer: It's the driver module that decides what you're in.
Steven Pemberton: Namespaces are only used for defining which version you're in. You can't just add something if the element isn't in a namespace anywhere.
John Boyer: So taking the instance element, in the data island module. So do go back to W3C and say we need namespace URIs.
Steven Pemberton: I'm not sure. The SMIL state is a data island in our definition; they've called it something else and it's in the SMIM namespace. I don't necessarily see a reason why we have to have a different namespace for different modules.
John Boyer: We could have a per-module namespace URI, but even supposing we did, what I thought you were arguing is that we needed one because we could move namespaces.
Leigh Klotz: My arguments were only about namespace URIs for XPath functions, not about multiple namespaces for elements.
John Boyer: I thought XHTML2 was importing XFoprms into its own namespace.
Steven Pemberton: Yes.
John Boyer: And events, too.
Steven Pemberton: Yes, which is why namespaces were invented in the first place.
John Boyer: So if we define a separate namespace URI for each module, is it sufficient to say that the module is intended to be imported?
Steven Pemberton: I think modules exist independently of namespaces. Namespaces are a result of creating a language.
John Boyer: So in the data island spec, you define the instance element without saying anything about namespace.
Charlie Wiecha: Yes.
John Boyer: So we need a URI just for XPath functions. Could we just define a context function in the extension functions and let other people decide what namespace they want to put it in? That seems like the opposite of the exslt approach.
Charlie Wiecha: Right.
John Boyer: It seems like we need the URI to say what we're adding it to. We're creating a function and it's being added to the extension functions group. What do you think, Leigh?
Leigh Klotz: I think we can decide which way the arrows go and what color they are later and should uplevel this.
Charlie Wiecha: I am not an expert and have to defer to you guys.
John Boyer: OK. Upleveling.
John Boyer: I assume the instance() and id() function are optional to implement?
Charlie Wiecha: Why? The IDL isn't optional if you have a DOM implementation. Although the must is nor formatted correctly.
Leigh Klotz: So what if you don't have an XPath implementation?
John Boyer: If you don't have at least one of the instance function or the getInstance document, then we're really not defining any way to interact with the document at all. It's like the cat in the box.
Leigh Klotz: It's not like we're giving out prizes for implementations that do nothing detectable. If you don't have XPath, you can't implement XPath functions.
John Boyer: If you do it, it should be done this way.
Leigh Klotz: What's the threat model?
John Boyer: Interoperability.
John Boyer: It can be optional.
Leigh Klotz: So put the instance and functions into their own modules and if you implement XPath. You create a similar one with JavaScript functions.
John Boyer: We decided to use XPath.
Leigh Klotz: DOM defines IDL and includes Java and JavaScript and other bindings, but not all of them.
John Boyer: We could put the functions in.
Leigh Klotz: If XPath is required, then we can live with it in there.
Charlie Wiecha: We decided not to put JSON in.
John Boyer: So we'd have to generalize the data reference format if we generalize the data format.
Leigh Klotz: So I hear that XPath is a requirement.
John Boyer: Yes. At some point in time we may do something else.
Leigh Klotz: So then we can put the XPath functions back in the module.
John Boyer: You can invoke the getDocument and use DOM manipulation; I'm not happy about that, but the ship has sailed. The only referencing mechanism we support is XPath. Into that referencing mechanism, these various modules inject functions that relate to their functionality. So XPath is recommended.
Leigh Klotz: Why isn't XPath required then?
John Boyer: Because you can use the data island without using binding attributes.
John Boyer: So why not go for the smallest data island spec and put the XPath where it gets used?
Charlie Wiecha: In the manipulation spec. Or the binding attributes module.
John Boyer: Can you reasonably use these functions without having binding attributes?
Leigh Klotz: How about value?
John Boyer: They take their in-scope evaluation context from binding attributes. You can't get them without acknowledging the in-scope evaluation context.
Leigh Klotz: So we can't use output without ref?
John Boyer: The behavioral contribution comes from ref.
Leigh Klotz: Although I could see data islands and output, but you rapidly want repeat or input, which brings you ref.
John Boyer: Yes. So for now we move instance and id to binding attributes.
Charlie Wiecha: Sounds great.
John Boyer: That's an action item.

Action 2008-10-15.1: John Boyer to add instance() and two-parameter id() functions to the binding attributes module.

John Boyer: Can we call it modules in one spec? Steven? Suddenly the one umbrella spec includes one thing.
Leigh Klotz: Why don't you just make xmlspec make 5 specs for you?
John Boyer: I'm too lazy to get xsltproc. Java XSLT processor doesn't know how to make multiple specs.
Nick van: [irc] xhtml modularization does that (multiple modules in one spec)
Steven Pemberton: It absolutely does that.
John Boyer: Does that seem alright to leave them in one spec?
Charlie Wiecha: Yep.
John Boyer: I'd like to put one first working drafts / last call.
Charlie Wiecha: And data layer. One with chapters.
John Boyer: I'm in favor of that. I think we'll get less blowback from W3C if we do it that way. I think Mark is the only person who objects to it. If we have shippable products, bundling them together is not a big crime.
Charlie Wiecha: It's a marketing question; will people realize they are useful?
Leigh Klotz: Or will they be useful? If we don't do the work, we won't know.
John Boyer: The data island module is useful by itself.
Charlie Wiecha: ...
John Boyer: But not the binding attributes module. And the data manipulation module.
Charlie Wiecha: But maybe not the ...
John Boyer: We could put out the data island spec by itself.
Leigh Klotz: It seems like a success to me to publish data islands by itself without namespaces or XPath.
John Boyer: It's already a separate module, as is binding attributes. I'm not sure there's anything for the actions module yet, because of XML Events 2; there may be nothing to be had. The data layer seems to be three separate specs. It's just that somehow the functions module seems a bit of overkill.
Charlie Wiecha: I withdraw my suggestion.
John Boyer: It makes it easier.
Charlie Wiecha: Leigh's point still stands; there's still heavy work to decouple them and make them work.
John Boyer: These all seem like low-hanging fruit. The decoupling remains for the model.
Charlie Wiecha: I don't understand how to use data manipulation without data islands.
John Boyer: Or binding. I can see binding without data manipulation, and data islands by itself.
Charlie Wiecha: So there was a suggestion we could use data manipulation in a document without data islands, decoupling the targeting of events.
John Boyer: What about the use case and the in-scope evaluation context?
Leigh Klotz: You could imagine setvalue/insert/delete applied to with context being the running DOM and abstracting over setting attribute values and non-mixed-content text children (no structural modification) with limited structural modification via insert and delete, and the target suitable defined, and write an article about using it in JavaScript instead of the various existing hacks that have replaced document.write, as higher-level mutations (as Charlie said).
Charlie Wiecha: Well put.
John Boyer: ...
Charlie Wiecha: You could re-use the binding attributes module and redefine the concepts.
John Boyer: It's not even hard if the consuming profile pulls together data binding and attributes; it might define particular instances as default; otherwise, as Leigh's pointed out, just using data island and data manipulation, the binding attributes are useful but the default is different.
John Boyer: I think that if we make in-scope evaluation context more generic in binding attributes, there's nothing different to be done in the data manipulation module.
Leigh Klotz: That was Andrew Watt's comment, that the context should be the root of the document, not a separate DOM.

John Boyer: Ok, so there's points now in the future features list that talk about the in-scope evaluation context and the target of insert/delete.
Leigh Klotz: So that's the reason I proposed genericising the instance attribute, so it can set the context, and insert/delete can find the instance. We can default it, and we can have insert/delete find the instance from the context, or use document root if that's the context.
John Boyer: So we can add instance attribute to binding attributes.
Leigh Klotz: Can we use binding attributes without instance?
John Boyer: No.
Leigh Klotz: OK.

* Tomorrow

John Boyer: Tomorrow we can do this same deep dive for the model module.
Leigh Klotz: Do we want to do this again or do we want to work top down in model?
John Boyer: It's been quite useful. We've had the roadmap.
Charlie Wiecha: Yes.
Steven Pemberton: +1