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
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.
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 http://www.w3.org/2008/uri 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.
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