Alain Couthures, AgenceXML
Dan McCreary, Dan McCreary
Leigh Klotz, Xerox (minutes)
Nick van den Bleeken, Inventive Designers
Philip Fennell, MarkLogic
Steven Pemberton, CWI/W3C (chair)
Erik Bruchez, Orbeon
Kurt Cagle, XMLToday
Steven Pemberton: XForms is used by development agencies. They would like someone to talk in Dar es Salaam, Tanzania. June 4-5.
Leigh Klotz: Can we put this on the news page?
ACTION-1792 Steven Pemberton to put this on the news page: http://lists.w3.org/Archives/Public/www-forms/2011Apr/0003.html
Alain Couthures: Another talk by Michael Sperberg-McQueen
ACTION-1793 Steven Pemberton to put this on the news page: https://dh2011.stanford.edu/?page_id=507
Alain Couthures: What is the right
type for input or textarea? So why is string the default type for
input?
Steven Pemberton: What breaks if the
default type is a string if you bind input to it?
Alain Couthures: A textarea control. I
cannot differentiate them by type. If I look at type of data, if
string, it should be textarea to correctly edit it, so everything
should be a textarea, that's the problem. If it's a normalized
string...
Steven Pemberton: If the default type
were normalized string then you couldn't bind a textarea to
it.
Alain Couthures: A textarea could
edit, but it should be a string.
Steven Pemberton: The answer is that
the default type is (a) the most general type and (b) the thing
that matches what HTML does, so if from a lazy point of view if you
put "message" as the name of the element bound to textarea, it
would just work. So it's to make it the most general datatype. If
you bind a textarea to a normalized string it breaks, but if you
bind an input to a string, it doesn't break.
Alain Couthures: Yes.
Steven Pemberton: So what are you
trying to do that this makes difficult?
Alain Couthures: I'd like to choose
the control from the XML.
Steven Pemberton: You're generating
the form? It's hard to automatically choose an input element if
they don't choose a type?
Alain Couthures: Yes.
Steven Pemberton: I think, unless
there are other answers, that this is unfortunate but true.
Erik Bruchez: I understand a bit of
what you're saying. I didn't think about normalized string type,
but I had in mind that normalize-space would merge spaces within
the string but that's not the case. So if the default type is one
that not everyone has heard about that could be a problem. Another
thing is that if you look at an XML document, within an element
without mixed content, by default you can have (almost) any string,
so that would be a departure from the default content in XML. Are
there other ways of achieving what you want to achieve?
Alain Couthures: I don't know what
datatype I should use from XForms to say that I want a textarea
instead?
Steven Pemberton: What about
xml:space? You can't say it's "kept" though. There's no easy way to
see from a document whether spacing in an element is kept or not.
If it's automatically generated controls, then perhaps the presence
of a newline would be enough to use textarea.
Alain Couthures: I'd like to use
xsi:type or schema to say how to edit the data.
Erik Bruchez: The schema types are a
horror. I like the idea that you could have a default mapping for
one-line text and then define an input.
Leigh Klotz: You could define your own
type using pattern.
Steven Pemberton: Or just use
normalizedString for input and not for textarea.
Erik Bruchez: There's something I'm
not getting yet. Is this generating a form with XSLT? If you have
an XForms document you have to have either input or textarea; we
don't have an XForms foo element.
Alain Couthures: I don't like the
textarea control; we could just use input and use a type. So
choosing a type for textarea for input automatically.
Erik Bruchez: Specifically, right now,
do you have a concrete problem with a document and a schema and you
want to produce a document?
Alain Couthures: I'm building an XML
editor from an XML document that adapts to xsi:type, so why not for
textarea.
Steven Pemberton: Really, what you
need is to say on the element that you want spacing
preserved.
Alain Couthures: Spacing
editable.
Steven Pemberton: Yes, same thing. If
it's normalized then the spacing isn't preserved. So you could say
if it has xml:space="preserve" then you get textarea, otherwise you
get input.
Alain Couthures: But that requires an
extra attribute.
Leigh Klotz: The spec doesn't require
much about textarea or input. Both say free-form data entry. But
textarea says "intended for use in entering multiline
content."
Steven Pemberton: You could edit an
integer with textarea.
Erik Bruchez: I'm not sure there's
anything we could change. A string could represent the input
differently for normalized string. The drawback is that you'd have
a page full of textareas.
Kurt Cagle: If you're using an
xml:space attribute, it should be on the model element being
referenced, not the control.
Steven Pemberton: Exactly, it has to
be on the instance. We're thinking of a way for Alain to
distinguish between strings where newlines are intended and where
they are not.
Steven Pemberton: Is that enough of an
answer for today?
Alain Couthures: Yes.
Alain Couthures: It's now possible
to have an XML editor within a browser. Many things can be used to
show what XForms can do. I would like to implement EXI as
well.
Steven Pemberton: Does it deal with
mixed content?
Alain Couthures: No, I haven't tried.
The first version, doesn't let you add or delete nodes, only change
values.
Steven Pemberton: But it's completely
generic?
Alain Couthures: Yes.
Steven Pemberton: I see you save to
file://. Does that give you a dialog?
Alain Couthures: Yes. That's what I
implemented in XSLTForms.
Steven Pemberton: So you always get a
dialog.
Alain Couthures: For security reasons,
I think it's required.
Steven Pemberton: Which version of
XSLTForms does it work with?
Alain Couthures: The current beta
version.
Steven Pemberton: So no question, just
a request for feedback.
Steven Pemberton: From Daniele
Ippoliti
Alain Couthures: For me it's about
subforms.
Leigh Klotz: Or components.
Leigh Klotz: I nominate Erik to say
he's got it implemented.
Erik Bruchez: Having a component you
don't have to duplicate is a little better. It's a bit old but I
can reply.
Steven Pemberton: Please do.
Kurt Cagle: I have most of this
up.
Steven Pemberton: Can we do this next
week?
Kurt Cagle: Yes. Oh, I may not be here
because of the MLUC.
Dan McCreary: I have done some work
for this to gather links on the wiki. I found some residual
artifacts from the tree controls in the past with sample markup,
but I'll need more time. jQuery has a huge number of tree controls,
but I'm looking for a 90/10 straw proposal.
Steven Pemberton: I recall X-Smiles
had a tree extension. http://www.x-smiles.org/demo/xforms/folders/xhtmleditor.xhtml
Alain Couthures: Also ajaxForms has
a tree control, but it's not in XSLTForms. http://ajaxforms.sourceforge.net/samples/addons.html#
Leigh Klotz: And Orbeon.
Erik Bruchez: It's very simple, not
general-purpose. It's a way to represent a selection control.
There's one for xf:select and one for xf:select1.
http://wiki.orbeon.com/forms/doc/developer-guide/xforms-controls/selection-controls#TOC-Tree-appearance
Kurt Cagle: I've been reading the
XBL spec. We're looking at a requirements document now.
Steven Pemberton: This Friday is HCG.
I will report status.
Kurt Cagle: We're putting together a
requirements document showing what's out there adn what's required
and we can't say that we're going forward until we do that.
Kurt Cagle: Norm Walsh put together
a general summary of the use cases and published it a couple of
weeks ago. I suspect this will be the result of the task force.
Also, it looks like Sam Ruby and the chairs of the HTML Task Force
have decided on preserving namespaces for RDFa.
Steven Pemberton: Yes, I'd heard that
some decision was made with xmlns prefixes would be preserved, but
I thought in the HTML version as well.
Kurt Cagle: Yes.
Steven Pemberton: There's someone
working on an HTML version of RDFa and since you need prefixes for
the values of rel and so on, there still needs to be a means for
declaring prefixes. Which is in itself good news.
Dan McCreary: I looked at the four
ways that people are adding rich text editors to XForms in the
field. I looked at Orbeon, betterForms, eXSLTForms, and IBM Forms.
Both Orbeon and betterForm use the mediaType in textarea, and both
are server-side and use extra libraries. The IBM Forms product (and
I have asked John Boyer for a definitive answer) have a text-type
attribute "text/rtf" then they do display an RTF editor. The word
RTF is often associated with non-XML representation of markup in
word-processing, so we may have confusion about RTF tags or HTML
annotations within a text area. We will have some interoperability
issues at this point. I have not seen any efforts to address
profiles of what tags should be accessible within the rich text
editor. From what I understand, everything is custom. So I will
continue to look at the other standards. So if it's a democracty
mediatype="text/html" seems logical since it's what the most use.
Also TEI has a mime type.
Nick van: We have a rich-text
component in our implementation as well, and we use XSL-FO. We
transform to HTML in a browser. For us it would be nice to plug in
extra languages in the markup.
Steven Pemberton: So you want
different mediatypes.
Nick van: So not just
mediatype=text/html.
Steven Pemberton: I think Dan said he
intended to look at the subset of HTML that people were doing now
so we could evaluate what level.
Dan McCreary: That's on my Todo list.
This area could have a huge impact. I'm trying to build a platform
for future work and want to acknowledge existing production systems
and the limited portability between them, and start small for
future work.
Kurt Cagle: In addition to TEI, I
think you should consider DITA as well. It's a large, active
community needing an underlying rich markup capability. If we have
rich context markup in a node, increasing it looks like that
internal rich markup is something we need to look at.
Steven Pemberton: This is very closely
related to Alain's generic XML editor. If we can find some way to
merge the two into a generic solution, that would be our strongest
card.
Kurt Cagle: content-editble in HTML5
will bring up the same issue. So we can have a block of content
that effectively is open to interpretation of an particular
annotation engine. One idea to think about (I saw this at Avalon)
is a path attribute that finds a mapping within a content-editable
region and a corresponding underlying XML representation to map
between the two. A div or span, and a map to the external
entity.