Charlie Wiecha, IBM
John Boyer, IBM (chair)
Nick van den Bleeken, Inventive Designers
Steven Pemberton, CWI/W3C
Uli Lissé, DreamLabs
Leigh Klotz, Xerox
Keith Wells, IBM
John Boyer: It looks like I will not be able to get to the TP. I would like to postpone the XML Security group meeting and post comments in lieu of meeting.
John Boyer: Nick, are you
comfortable with the new information on bind?
Nick van: I may come back with
questions later.
John Boyer: Next week?
Nick van: No, I will not work on it
tomorrow.
John Boyer: I assume it will insert
itself within the bind module. We will define the recalculate
action, the xforms-recalculate event for the model, the basic
recalculation behavior, the master dependency graph on rebuild, and
the pertinent dependency subgraph on recalculate. This module is a
consumer of the changelist from the model. It will contribute to
the changelist. The results so far have clarified what needs to go
there. Anyone else?
Leigh Klotz: We should make sure we
think it can't be used outside of bind.
John Boyer: We would attach directly
to UI controls in the simplified syntax. I see your point: it is
defining an attribute, but not necessarily what element that
attribute is being applied to.
Leigh Klotz: It sounds like we have to
decide how calculate gets added to bind.
John Boyer: And the others, too.
Leigh Klotz: The MIPs, but not the
other attributes ref and bind.
John Boyer: I wish we'd called type
datatype since HTML already has a type attribute. Datatype is an
exceptionally good name since we've whittled downt the type to
Schema "datatypes."
Steven Pemberton: [irc] RDFa already
has @datatype.
Leigh Klotz: [irc] Mark said that was
OK.
Steven Pemberton: I don't know how
that will work.
John Boyer: I think he said he'd take
it back to RDFa; as far as he could tell it was the same thing.
Since it fuels processing for us and RDFa derives metadata it's
ok.
Steven Pemberton: As long as they
don't happen on the same element. If you want to put the RDFa
datatype on and ours.
John Boyer: I think that was OK
because it's two processors reading one attribute for two reasons
but the attribute was OK for both operations.
Leigh Klotz: The question is are the
value spaces the same?
John Boyer: Are they? If not, that's a
real problem. I think we ended with the fact that they were the
same, but I could be mistaken. All of this is in the non-namespaced
world.
Steven Pemberton: You agree that you
could put them on the input element?
John Boyer: And not
namespace-qualified. If I say a datatype is a date and RDFa says
it's a date, and in Forms we take the date to cause us to use a
calendar picker and in to generate a data node validated against
the data type of date, and RDFa does what it does...
Steven Pemberton: In RDFa it talks
about the content attribute and in Forms it talks about the ref
attribute.
Steven Pemberton: <input ref="n"
property="event:start" datatype="xsd:date"
content="2008-10-16">
John Boyer: The content attribute is
like the value attribute. In XForms datatype is about the stored
node.
Steven Pemberton: It's the
generalization of HTML meta. The content attribute overrides the
element if present.
John Boyer: I could see a form
processor in which the content of the node referenced by ref is
placed into the content attribute.
Steven Pemberton: I could see that
cooperation.
John Boyer: In which case having the
datatype there doesn't seem to cause any harm.
Steven Pemberton: My only real problem
is that RDFa is often automatically generated so you don't
necessarily know when you're composing your page what attributes
end up on the elements. For example, Drupal, which is a
content-management system, is now seriously adding RDFa. My worry
is that you might author an element with a ref and a datatype and
the CMS adds a content attribute and a datatype and now you've got
two.
John Boyer: Then that's broken
code.
Steven Pemberton: It's still a
conflict. Someone is processing a pre-authored form and changing
the datatype. It doesn't make sense for the control to say that for
XForms I'm one type and for RDFa, another. Mark may have seen some
way.
John Boyer: It sounds like it's
misnamed.
Steven Pemberton: It makes a statement
about the content of the element. For exampl
Leigh Klotz: From http://www.w3.org/TR/rdfa-syntax/
<span property="cal:dtstart" content="2007-09-16T16:00:00-05:00" datatype="xsd:dateTime">September 16th at 4pm</span>
John Boyer: It's consistent; I see
that it's avout manipulating content.
Steven Pemberton: If we consider that
the ref produces the contents of the element, then we're safe. We'd
have to explicitly state that. The problem is that ref produces
dynamic input and RDFa is about scanning the document and not
running it.
John Boyer: If you find an element
with no content perhaps you should resolve the ref, just like
resolving the src in other contexts.
Steven Pemberton: Only by running
it.
John Boyer: Only by executing that
XPath or UI binding. They can decide they don't support that level
of indirection. If someone has typed something in does it get
serialized again? Form controls are for interaction.
Steven Pemberton: There are hreftype,
srctype, etc. It might be worth calling it reftype.
John Boyer: Or data-type. This is a
Webforms-A diversion; it's still type in XForms.
Leigh Klotz: If we don't have on
inputs in XForms 1.2 then we don't need data-type in XForms 1.2,
just in WebForms-A.
John Boyer: Right, it's not part of
XForms modularization.
Leigh Klotz: So the discussion we just
had is on WebForms-A and has no bearing on XForms 1.2?
John Boyer: Right. Well, it does have
some bearing because of the question you asked a while ago: do MIP
modules have to know about bind. We ended with the answer that
potentially the driver would apply calculate to bind, or to UI
controls. Likewise, the type attribute is applied elsewhere. And
that's where we run into trouble.
Leigh Klotz: Perhaps WebForms A will
need glue anyway, and can't just use the calculate module.
John Boyer: The glue woudl at least be
context=.. and could rename type.
Leigh Klotz: I'm happy enough for now
on that.
John Boyer: There are three modules. The first defines constraint, required, and type, has picked up the revalidate action and the revalidate event for the model.
John Boyer: The XML Schema
Validation module injects the model attribute and Schema element
into the model. That module also appears to be the module that
processes xsi:type. If you're not doing XML Schema validation,
they'd be ignored. Then there's full schema validation (see bullet
points), or structural validity information for submission. We
haven't talked about submission yet.
Uli Lissé: I have a question
about the schema attribute. We might want to add other Schema
languages such as Relax NG. Would we define a module for
this?
Leigh Klotz: http://www.thaiopensource.com/relaxng/nrl.html
describes a better way of pairing than the schema attribute string
pairs of namespaces and schemas.
Uli Lissé: Where would we put
the rules document?
John Boyer: In the body of the model,
just like xs:schema.
Leigh Klotz: So when we get to
multi-schema routing I would recommend we use this.
John Boyer: So we don't need to move
the schema attribute out of the schema module.
John Boyer: We split this into three so we can have XForms datatypes (xsd union with empty string) available even when someone doesn't want XML Schema validation.
John Boyer: So do we need the types
separate from the constraints and validations?
Uli Lissé: I think so since it
can cause an input to render a calendar control.
John Boyer: Unless you have the type
MIPs.
Leigh Klotz: Isn't the type lib just
an XML Schema file? Can't someone else use it on server-side
validation?
John Boyer: We're modularizing for web
authors to incrementally consume pieces. Do we really need a
separate spec? It could just be the last chapter in the validation
spec. It makes the type MIP easier to consume.
Leigh Klotz: It doesn't have many
implications on other things it we publish it stand-alone or not. I
think the choice is for its own sake.
John Boyer: I like them together; is
anybody opposed?
Leigh Klotz: My point is it's not on
the dependency graph, so we can do it however we want today and
change it later and there's no effect.
John Boyer: Somebody has to write it
real soon now.
John Boyer: Is there any confusion
about this? It contributes to the behavior of the validation
module. I think it doesn't contribute to the submission module any
more. We put required-but-empty back into validity so submission
can just use what revalidate-event does. So we can talk in terms of
the XML Schema validation module in terms of how it contributes to
the core validation module, and submission module inherits that. We
already fixed that.
John Boyer: It's a little funny that
we define instance node validity in an event whose default
processing is to insure validity of all nodes. Just in terms of a
spec that talks about validation. If you look at the
xforms-revalidate event in Section 4.3.3 in XForms 1.1 Editor's
Draft...
http://www.w3.org/MarkUp/Forms/specs/XForms1.1/index-diff.html#evt-revalidate