Charlie Wiecha, IBM
Erik Bruchez, Orbeon
John Boyer, IBM
Nick van den Bleeken, Inventive Designers
Steven Pemberton, CWI/W3C
Leigh Klotz, Xerox (minutes)
Charlie Wiecha: Here's the
draft:
Charlie Wiecha: Many of the questions
are about what @resource means, especially on import. There's a
notion of a similar mechanism for a source for original content. I
have questions about how it should work. Let's discuss the syntax
first.
Charlie Wiecha: mode/@src,
model/@resource, model/import. (Where do the serialized instances
go.)
Leigh Klotz: Not being able to import
the same instance URI twice seems like a design problem.
Charlie Wiecha: For the syntax, I
assume that it points to an outermost model element. Then schema
and function definitions can be on the model element of its own.
The first example is a model with no inline content. See section
1.1.1.1, remote model content example.
Charlie Wiecha: Is that structurally
consistent?
Leigh Klotz: We'll have to a separate
schema for the remote model.
Erik Bruchez: It can be just a
type.
Nick van: First it's a new root
element.
John Boyer: Why is type and resource
in it.
Erik Bruchez: A model with a single
import is equivalent to the attribute.
Nick van: If it's the same as instance
you can't have content in the model with src but you can with
resource.
Charlie Wiecha: Do we need to discuss
the schema?
Leigh Klotz: Let's just note that we
will need a schema for this.
Charlie Wiecha: OK.
Charlie Wiecha: What we mean by child
content is the question; is it just instance data or is it
declarations as well?
John Boyer: I thought it would be the
same as on instance.
Nick van: Then you don't merge; you
ignore the content.
John Boyer: That's why import is
seeminlgly more valuable.
Charlie Wiecha: The same question
comes up; do you save the declarations as well?
John Boyer: For @resource you save
everything.
Charlie Wiecha: In the import?
John Boyer: Yes.
Charlie Wiecha: So if there is any
content those would be preferred.
John Boyer: Yes.
Charlie Wiecha: What about cascading
imports? Where do you serialize the content of the second?
John Boyer: Turtles all the way down.
The processing model will make them all available.
Charlie Wiecha: Yes, all at the root
level.
John Boyer: But syntactically, all are
imported.
Nick van: I'm not following; save is
something the application does?
Charlie Wiecha: It's by analogy with
instance @src and @resource.
Nick van: Then why do we need the
import to be left there? Is it not resolved and then the import is
gone?
Charlie Wiecha: I came up with Erik's
reminder that you haven't built a single infoset. You may carry
them as separate infosets and merge them as one model. You may have
a problem of saving a compound document. Or you may build a nested
structure, modifying the original document. It's a bit bizarre
either way you go.
John Boyer: I wouldn't mind if it were
behave if merged but still inside the elements.
Charlie Wiecha: Parse as separate
fragments?
John Boyer: We preserve the import
elements so you preserve the original "somewhere else" but if you
make markings in the infoset, you can ..
Nick van: Why do we need that?
John Boyer: I don't know yet. It might
help resolve ID conflicts.
Nick van: It looks much simpler if you
just have @src and @resource and have the extra functionality
simply resolve import.
Erik Bruchez: What is this save
stuff?
Charlie Wiecha: It's like saving a
form with inline instance data.
Steven Pemberton: File save in the
browser, for example.
Leigh Klotz: John has implemented save
with @resource data inlined.
John Boyer: It's saved as a single
document so it can be signed, with instances and all external
resources available.
Nick van: I agree that that's a use
case we should support but I don't see why the application can't
serialize the merged model content in the document.
John Boyer: If you didn't retain the
import element, then you'd have to put its content in place of
where the import element is, and take any attributes of the root
level model and escalate them to the corresponding attributes of
the toplevel model element.
Charlie Wiecha: Some imports may have
src attributes and need to be reloaded when the model is loaded.
... You have to maintain the import chain.
Nick van: For save, don't you want
everything inline?
Charlie Wiecha: It's like a form today
with @resource and @src.
John Boyer: Yes, for @src we continue
to reload.
Charlie Wiecha: In general you have to
keep the import chain.
John Boyer: Why does keeping the
import chain make the processing harder?
Charlie Wiecha: I don't think it does.
You mirror the chain. Some may have @src inside so you have to
restore them.
John Boyer: Leave open for cleverness
for finding where model rules came from.
Nick van: Why only @src now @resource
on import?
John Boyer: So I can save it.
Charlie Wiecha: What about just doing
it on instance?
John Boyer: You'd lose the
instances.
Nick van: In XSLT, does import resolve
conflicts? What if both define the same instance?
Charlie Wiecha: I came across that
issue as well.
Nick van: In place overrides?
John Boyer: You may have to merge
model attributes. But why?
Nick van: ...
John Boyer: Why is that harder to
resolve from inline import content?
Nick van: You can put everything in
the model.
John Boyer: Does it need to reload a
second time?
Nick van: If defined inline it
wins.
John Boyer: How do you know?
Nick van: Merge model attributes on
top model when you load. Binds and instances go into model.
John Boyer: How do you know the bind
is already there.
Nick van: If it has the same id.
John Boyer: What if it doesn't have an
id?
Charlie Wiecha: These are the two
paths I was going down: either the stuff merges into the root model
and we figure out how to reload, or we preserve the import
chain.
Nick van: You duplicate stuff in the
second case.
Charlie Wiecha: It's not there in the
runtime.
Nick van: Why do you need to keep it
in the source?
John Boyer: It makes it easier to
parse.
Nick van: An implementation can drop
the imports if everything is inlined.
John Boyer: The alternative is that if
you inline content, you delete the import statement at that
point.
Nick van: You need to work it out so
that the inline content wins but we have to work out the no id
problem.
John Boyer: Sounds difficult.
Charlie Wiecha: That loses @src on
import.
Erik Bruchez: I'm confused. What are
you signing? You can serialize a non-import version and reload
that.
John Boyer: That doesn't work if you
snap in a standard XML signature engine; it doesn't know any custom
canonicalizations.
Nick van: You can just update your
XML.
Charlie Wiecha: How can you drop
import/@src.
John Boyer: Nick's saying you just do
it once.
Erik Bruchez: We have a way to offload
a form from memory, static and dynamic information. The dynamic
info is current instance values. We save and restore that, not as
XML, but we could. Schemas and external instances are stored as
part of the static information.
Charlie Wiecha: That's the aha. Maybe
we only need the @src on instance and everything else is all
promoted to the root document as static content. instance could
have @resource or @source. The resource function is only on the
instance element.
Leigh Klotz: @src on instance in the
face of save/restore sounds dangerous; it would discard changes and
can't be signed.
Charlie Wiecha: You make it sound
bad.
John Boyer: We seldom use
instance/@src.
Nick van: You need to use it
offline.
Charlie Wiecha: It sounds big.
John Boyer: It's DOM in the runtime
anyway. It doesn't matter where you got it from.
Charlie Wiecha: Let's get back to
import replacement.
John Boyer: I like resource for
application signing. When I want a signature that lets you sign a
tax form. If I say not to sign the resource attribute instances,
I've signed the application. That lets you change the content of
the instance element, but not anything else (binds, etc). I know
the instance with resource changes at runtime. It's harder for me
to express that if you delete the import and add stuff in its place
so I can't find it after it's been done to characterize omitting
it. That's why putting it as import element siblings is hard as
well. Inside the import works.
Leigh Klotz: It doesn't sound like
that much of a problem to me.
Erik Bruchez: Can we summarize what
you would like?
John Boyer: @src and @resource would
act like they do on instance. import/@src would fetch binds or
submissions or whatever, and make them available to the containing
model. With a @resource, it would make them available to the
containing model, but also store them in the import element.
Leigh Klotz: Do you want @src? Just to
put a fine point on your use case.
John Boyer: I don't need it for my use
case.
Erik Bruchez: And by storing it the
element in the import?
John Boyer: Those binds or
submisssions would be placed in the element.
Erik Bruchez: You mean in the
DOM?
John Boyer: Right.
Leigh Klotz: This is a formal
definition, so that we say import with children is the same as a
resolved @resource import. So John can use that formal
definition.
Leigh Klotz: I see no value for
import/@src. I separately see no value for instance/@src wither and
would prefer it replaced with the better-defined
instance/@submission.
Erik Bruchez: I don't like
import/@resource modifying the DOM. I think import should merge as
in RelaxNG.
Charlie Wiecha: It's like
instance/@resource.
John Boyer: What if I called it
submodel?
Erik Bruchez: If it's called import we
have to worry about that, but even if it's called foobar, I have
yet to see an element causing a modification to its own
source.
John Boyer: instance does that.
Erik Bruchez: Instance creates a
shadow tree.
John Boyer: It's like content merging
in XBL.
Nick van: It's a shadow DOM.
Charlie Wiecha: The inline content is
used.
John Boyer: We aren't saying you have
to merge; just saying that the resource attribute would be the same
if you did it. You don't merge unless you have save/restore.
Erik Bruchez: Leigh was saying that it
was a formal model.
Leigh Klotz: Yes, this is just Beta
reduction from lambda calculus. We might consider Alpha rename if
we want to resolve bind id conflicts, or skip it knowingly if we
decide not to. If there's no reflection access then you can't tell
if it's actually included, but if you save and restore it would
behave the same way.
Erik Bruchez: I think it's adding
complexity to say you can restore it. We always load stuff on the
side.
John Boyer: The key rule that we need
in XForms is that @resource will not be resolved if there is inline
content for the element. Then if you don't want to do save/restore
then you don't to do it.
Leigh Klotz: We do have to keep this
use case in mind because you can't sign things using Nick's
proposal for replacement.
John Boyer: We don't need to say that
it gets put in at the DOM level.
Erik Bruchez: I have two problems. I
want inline vs. resource to work the other way. I want default
inline instance. So without knowing about signatures, I find it
counter intuitive. So when we just need to bring it to model I
start to cringe.
John Boyer: You want to use @src for a
backup for when resource fails?
Erik Bruchez: Inline content as a
backup for @resource failure.
John Boyer: That's what we get from
the @src.
Erik Bruchez: I thought we dispatched
an error.
John Boyer: We could do that; instead
of xforms-link-exception we could use inline content.
Erik Bruchez: Right now we
can't.
Charlie Wiecha: That's a good
idea.
Leigh Klotz: Or if you do my
instance/@submission idea the instance starts out with initial
content which is then replaced when the submission replaces
it.
Erik Bruchez: We can workaround foobar
instead of import but it's still confusing.
John Boyer: It's a different use case:
a runtime document that can be digitally signed at multiple
times.
Erik Bruchez: XSLT, Schema and Relax
all have import. They all have rules for conflict; first one ones,
higher priority, errors, overrides.
John Boyer: None of these involve
runtime user interaction or a complex document lifecycle. Nothing
happens inside them. There's no save/reload.
Erik Bruchez: That's fine but it
doesn't change anything. I can imagine importing a model.
Nick van: For me, the important
question is whether the form author gets what he wants. Does the
form author want inline content to win? I think he wants to merge.
Maybe the application can fulfill this in another way. Like Erik
said, it's clearer with XSLT.
Charlie Wiecha: There's another
option, a compound document in a containing structure with merged
content. We'd have to define the archive format.
Erik Bruchez: John, how do you do this
with external resources? CSS files or images? How do you sign them?
How's that different?
John Boyer: Typically, the resources
necessary to completely characterize the whole user experience are
gathered in one document. For compound formats (ODF Package) the
supporting images are in there with relative URL references.
Erik Bruchez: So the same could apply
to the imported model. You sign it together.
John Boyer: Except that we're years
away from that. Right now we, and ODF, have one XML document.
Charlie Wiecha: It's a big jump.
Erik Bruchez: We have an internal
representation and could do our own serialization to XForms or a
modified version. Instead of import, you could do it yourself. You
apply and flatten your input into a single flat model.
Charlie Wiecha: We have a lightweight
process like that for instance; if we had something simple for
import that would be good.
Erik Bruchez: I feel this is a very
specific use case. The way to implement it is different. We seem to
have a solution, archive format, that seems a nice solution, if not
a beautiful one. I would have to make xforms more complex and
counterintuitive because IBM is a few years away.
Leigh Klotz: The XML applications Erik mentioned have both import and include, synonyms with slightly different behavior. So it's not fair to say that the names are well defined and easily understood; the different use cases there have slightly different uses. So we might be able to fix this by naming.
Charlie Wiecha: ...
Erik Bruchez: It's a feature of the
browser that you can save right now, but not a feature of
HTML.
John Boyer: I have an XML format and
several cases: applications, signature, save/restore. I don't have
a requirement that you must save it. I just need that you need the
inline content used in preference to resource. I don't see the
complexity in that rule.
Erik Bruchez: It's not implementation
complexity; it's a few lines of code. It's the notion that inline
content overrides remote.
Charlie Wiecha: That's more the issue
than modifying the infoset.
Erik Bruchez: It's both.
Nick van: I don't know if we need
inline content, but for authors, if we need it I think it's more
likely to be merged than replacing it. If you the form author wants
it inline, put it inline. It's a not a feature for the form
author.
Charlie Wiecha: There's modified src,
resource, and merging, for three use cases.
John Boyer: Merging sounds useful but
harder to define. The resource case says inline wins. The src case
says remote wins. Those are the two corner cases of merge.
Nick van: What if we have
inline?
John Boyer: In design tools we give
the template but then once the document is running we want the
template data included.
Nick van: Why keep
instance/@resource?
John Boyer: I can digitally sign the
application by signing all applications except instances.
Charlie Wiecha: It's a flag. You don't
remove the resource attribute.
Nick van: In XML Signature you could
say that if there is child content then you don't have to take it
into account.
John Boyer: No. If you use @src the
data would be thrown out.
Charlie Wiecha: Next time you load the
form.
John Boyer: Why make a more
complicated subtraction filter to remove an ignored
attribute?
Erik Bruchez: Why would a form author
ever write inline content and a resource attribute and want inline
content to win?
Charlie Wiecha: It says if you have
inline content under instance it wins.
Erik Bruchez: They are separate DOMs
though. It doesn't say it is modified.
John Boyer: It enables some use
cases.
Erik Bruchez: I understand that and I
think it is a hack, frankly. It is an incomplete serialization
format; it doesn't save repeat and switch state.
Leigh Klotz: We discussed moving those
to instance yesterday.
Erik Bruchez: If you want a proper
state-serialization for XForms you have to have...the author might
not use it.
John Boyer: It would be potentially
insecure if they didn't use it.
Erik Bruchez: You are looking for a
complete serialization mechanism but you don't have it.
John Boyer: The world isn't perfect.
There are rough edges. We don't have an unassailable document
format.
Erik Bruchez: Now we're adding more
features working "slightly" against the form author.
John Boyer: Does the form author ever
do this? Form authors use empty instance elements. The runtime does
it for them. At design time you specify the template for data or
the initial stuff. @src means runtime, @resource means initial load
time.
Charlie Wiecha: We don't have a single
schema for two but we should have two schemas.
John Boyer: There's the design-time
schema and the runtime. You can use multiple schemas at different
times.
Erik Bruchez: This is an IBM-specific
schema that is for a specific save format.
John Boyer: If you want @src to
default to inline content then you need inline content
anyway.
Leigh Klotz: It's not a serialization
format. I see instance/@src and instance/@submission as data that
gets reloaded at runtime, for example during browser page reload
and @resource means not to reload ever (cf. HTML4 page reload with
forms).
Nick van: The merge use case is
important.
Leigh Klotz: There's import and
include.
Nick van: Import does more; include
just replaces.
John Boyer: Merge is useful; it's a
separate feature. I agree with Leigh that there is a behavior we're
asking for for @resource, which is to resolve on first run. It also
enables the "hack" for inline content. I've used it in three or
four ways; the merging feature is different.
Erik Bruchez: I have a problem with
the notion of multiple runs; it's not part of XForms at this time.
It seems a way that some implementations deal with forms.
John Boyer: Yes.
Erik Bruchez: So I'm worried we aren't
considering full support for the feature.
John Boyer: It can already be
exploited in two or three ways. An application can decide at any
time to pre-populate the document with information. Or you could
have a save button that turns off pruning and they just do save.
They don't want initial template data.
Erik Bruchez: We do it differently,
with a REST API that has a function which loads a templae. When the
data is saved, it has an ID. We have an edit/continue which loads
the data through the API.
John Boyer: That's great for your
system; I have a document format I want to save to disk.
Erik Bruchez: You have a URL for
get/put/delete. When I load my form in "new" mode, I call
submission for PUT.
Leigh Klotz: As in xinclude could we
have a fallback element, an "inline" element for John, and a
"resource" element for they overriding URI.
Nick van: In Orbeon we use request
parameters and @if to do extra submissions to get the data.
John Boyer: If you assume a REST
service and a server you can do it. If you assume a document format
(and we have two document format consumers) there is a different
way to get these features.
Nick van: It could be a relative URI
that gets the resource out of the document format.
John Boyer: If you have an archive
format.
Erik Bruchez: The schema attribute
already supports ids. That could be a solution. Then we don't have
an archive format but we have everything inline.
John Boyer: I then have to re-write
the resource attribute.
Charlie Wiecha: I don't understand the
downside but it sounds like a good lightweight solution.
Steven Pemberton: John has to leave
now.