Forms FtF, Amsterdam, Day 3 -- 11 Jun 2008

<scribe> scribenick: klotz

Streamlined Syntax

john: we've talked about an xforms aggregator module, really XForms Full Aggregator Module, and a Model Only.
... then a streamlined module, which adds all the additional attributes to ui controls.
... does that seem like the right approach? add @relevant to input.

charlie: xf:input or html:input? that may imply a different driver, right?
... it just occurs to me that i don't really recall where we had anticipated them going last month

john: i don't see why they can't go on our elements

charlie: as a streamlined syntax, it's one of our options

john: do we put all those attributes on our elements?

steven: we still have to discuss and resolve whether it's ok for us to import xforms wholesale into xhtml2

john: without namespaces

charlie: there are two uses, for ourselves, and as an onramp

leigh: i think xslt as a way to do it

erik: so what about namespaces? i see people using prefixes now. i don't necessarily agree, but if you want to inject stuff into an html serialization it make some sense. i don't disagree with a language having multiple serializations.

charlie: so we'd be less "religious" about the mechanics of how the concepts are injected into other applications if you implement the semantics. none of this takes away a need for a driver.

leigh: that's why i said that a description, prose or xslt, would be a fine way to describe the mapping of html+extra into xforms

john: so that module gives something for the transformation to aim at
... we should have a talk about Nick's changes so we can look at them and see if they go into the streamlined syntax module and which go into core submission and core ui control

nick: it's not a lot of adjustments i've made
... [projects changes]
... i've created two new subsections, common submission attributes for submit and send (same table as before) and common submission child elements

leigh: is there a confusion between ref on submission and ref on submit

john: there is a difference

leigh: they're now defined in the same spot

steven: we use ref on submit

john: but it's a ui binding on submit and not on submission; you also have model attribute. do we now need model on submission? are we putting submission outside a model?

nick: no submission is still in model; i've made the resource optional and the submission element is still in the same place, with common attributes, but I need to redo it because of ref

leigh: and bind

john: it will combine with ref on submit; submit has ref/bind/model; submission doesn't have the model attribute.

<Steven> Yesterday's minutes now in place at http://www.w3.org/2008/06/10-forms-minutes.html

nick: model wasn't in this list.
... then you can't override what is submitted.

charlie: so you use these on the submit element?
... then put submission as child of submit; it will look a little weird but it will be clear

nick: i wrote that local submission elements override the referred submission so you can specify the resource locally.

leigh: so if we had a child submission element it would take precedence in its attributes over the id-referenced submission

charlie: or only its attributes if there is no reference

erik: I see, so you can bind the trigger to another node to control relevance and we'd lose that.

john: why isn't it backwards compatible?

nick: ...

john: you can still do it by using a full submission element.

erik: it has a different behavior for existing code: submit/@ref now implies the data to submit

uli: wouldn't it be much easier to include a child element of submission on submit

charlie: it's not clear where the events get dispatched, to the local submission or the model one; it's clearer when you put the attributes on submit

erik: what was the initial goal for overriding attributes on the submit button?

nick: it was for streamlined syntax so you don't have to have a submission in the model
... it also allows you to change the resource attribute in the submission for different submit controls

erik: so this is for no model, no submission, all ui?

john: i think we can just say ref doesn't override. then it's time to write a submission element.

charlie: i'm a little worried about special-casing it.

erik: the nested element solution isn't good for simple syntax

john: this has to boil back down to input type="submit" with a couple of other attributes. ref isn't even going to be one of htem.

nick: are we making this change to submit or input?

<Steven> Remote+Keith(remote)

john: it will happen from streamlined syntax

erik: but we don't have input type="submit"
... xslt can produce a submission attribute

nick: the sourceforge converter I posted does this, with modes in xslt

john: so it should be possible to write the html or xhtml module for xforms to do this

erik: so input type="submit" is equivalent

leigh: if this is for the onramp it should be doable with an xslt or a javascript library; for xhtm2 a module is fine

erik: so what is the next step for an existing html form? input type="submit". so what's t next step

john: that implies that we should have an input type="submit" that maps on to submission

leigh: we can define our own input type="submit"
... but who would use it? i can understand an xslt that maps html4 input type="submit"
... i can understand a module of xforms core additional support for the output of that transformation
... but i can't understand a module that adds xf:input type="submit" to xforms; who would use it?

charlie: but we want a streamlined syntax for our xforms authors

steven: is it a moment of simplification and a lifetime of grief?

<Steven> I don't see what it simplifies; MVC gives you long-term simflification

<Steven> I see streamlined syntax as adding the font tag back into xhtml to help people use stylesheets!

leigh: i think it's fine to have an html4 syntax library in javascript and an xslt or prose transformation to core xforms, but i don't see that the html4 syntax with javascript is the exact same sequence of characters that should appear in an xforms simplified syntax

uli: is this xml?

john: xml well-formedness is an illusion. they can use the same tags and attributes. they shouldn't have to throw out tag names and switch to xml and give up on attributes.

leigh: i can see the value of the xslt to convert html+stuff into xforms, and the value of a JS implementation of the same, but no value in an XForms module that adds the exact same attributes to XForms

charlie: but we want a simplified syntax

<nick> http://sourceforge.net/projects/xhtml-to-xforms

leigh: yes, that's great, but it's not necessarily the same syntax as the additions to html4.
... so I think there should be an XSLT or XSLT-in-prose for converting HTML4+attributes into canonical XForms, and a module that adds any necessary support for that, and an OSS JS library that for some high percentage of cases works the same in HTML4 browsers, and the XSLT could be a W3C note or even a non-W3C Note, but it's not a module of XForms
... Mark Birbeck and Paul Butcher arrive

<markbirbeck> Hey Keith. Are you managing to stay awake?

<markbirbeck> :)

mark: I think we should have a legacy module, as in XHTML2, to fully describe the HTML4 forms and it would be optional to implement, but it's an important part of the onramp. An XSLT wrapping isn't the same.

Erik: The DOM is different for example

Nick: There are some HTML4 attributes that are hard to implement.

leigh: I had thought we were going to implement features necessary to transform HTML4 into canonical XForms but just not maintain the HTML4 syntax as a spec.

paul: What attributes are hard to implement?

Erik: I see more of a jump than a progressive ramping up

mark: We've been doing those kinds of things...nobody's produced the finished example yet, but there's been discussion about those kinds of iterative steps

Erik: maybe it's my fault but I don't have it in mind. i think this discussion started with Nick's work on xf:submit and I didn't see how this helped us

Mark: This i old ground...we agreed there are two sides: now HTML form processing (model, logic, lifecycle, events) maps to XForms, and then if there are features in XForms that need tweaking to accommodate the symmetry.

Erik: But the submission can be done with a submission and a submit both, since it turns out we really want input type="submit"

John: I don't want gratuitous differences between submit and input type="submit" so we should add them to both. There are certainly differences between core xforms and streamlined syntax.
... For the simplification of core xforms tasks, unless there's a good reason to deviate, we should make an effort to make it look the same in both xforms simplified syntax and html4.

Leigh: I don't agree with the goal but 40% of example can convince me.

Mark: You have to have quite a bit of stuff on the plate to get, for example, a range in a form, then you need to know a lot of stuff.

Leigh: That's the core Canonicalization problem.
... But the question is whether the xforms simplification and the html4 complification result in the same language; I don't think so, but it's fine for John to want us to go that way for to keep trying for it as a goal, but I think it's a something has to be shown.

Erik: ...

Nick: ..

Leigh: ...

Mark: We're aiming at unobtrusive JavaScript, not arbitrary stuff. We're in the same space and direction and world view as these libraries. We're saying we should attach a particular type of model to this.

Nick: So the goal of ubiquity is an existing html form with all the javascript working? don't you have DOM problems?

Mark: In the modern libraries, it doesn't use the form submission; they use XHR. So they've already marshalled the normal flow. I can say that I can give you an event to start submission and some of them are doing this. We follow the specification for the specification.

Erik: But you're talking about how to implement ubiquity

John: We started this with a discussion of submission attributes on submit and that didn't work because of @ref. Then we talked about adding submission as a child element of submit, but I said that simplification looks different and isn't tag-parallel with input type="submit"
... So when we do XForms simplifications that aren't going to match HTML complifications, how seriously do we take that problem? That's all we have to resolve here.

Uli: For me the main point is to simplify the syntax without a model, as Mark said. Bt I'm not concerned about HTML4.

Charlie: That's what gets us where we are. But my main concern about Leigh's two tracks is that unless we actively grow it, are we ...

Mark: ...

Leigh: ...

Paul: I'd like to ask about ref on submit and submission. If you're calling submit with these shorthand submission attributes, you're not going to lose behavior on submit by binding it to a particular node.

Nick: The attributes that are local override the submission. In XForms 1.0 or 1.1 you can already have a ref attribute on submit for relevance, so in 1.2 that will override the submission ref.

Paul: OK

Erik: One solution was to say that ref and bind are not overridden; that's possible from a spec level but it doesn't work for authors.

Mark: What's the driving force for the abbreviated syntax?

Leigh: My question exactly

Charlie: It's not a simplification for the onramp. It's a good example of simplification for XForms that's misaligned with the "complification" track.

Mark: We already have a potential child element, send, and the attributes could go there.

Charlie: That also solves the event dispatch problem

John: How does it simplify anything?

Mark: I don't care too much about it anyway as I'm concerned on the HTML transformation

Erik: submit is simplified syntax for trigger+send

Mark: So why complicate it?

John: Because it doesn't have a submission element.

Mark: So what's wrong?

John: I'd rather attack it in the reverse direction. What do we want input type="submit" to look like? Then how do we write that without a submission?
... Do we need to make cdata-section-elements on submit? Really we only want 2 or 3 on input type="submit" and put those on submit and be done.

Erik: We tried that with the form element. So input type="submit" is all we need.

John: People know stuff about HTML forms today; they want to evolve their capabilities and add it one at a time via attributes

Uli: via javascript libraries

Mark: Dojo could add that feature, an xforms attribute in an unobtrusive javascript library on form. So it's an ideal gradual onramp to add attributes to the form element.

Nick: Nobody uses the action attribute on a form anyway; everybody uses javascript

Mark: You put it in the form action and the javascript does extra clever stuff.

Steven: But don't unknown attributes disappear from the dom in HTML5?
... So doesn't that break adding attributes processed via Javascript?

* Break

Charlie: I quite like this idea of a deprecated chapter.

John: What's the difference between a chapter and another module?

Uli: I thought the idea of modules, for message, for example, does it start an xforms processor?

John: It causes a set of markup to begin working in an implementation specific way.
... It's not done until we agree it's done...similar to the IDL discussion we had.
... To control the one submission, it's ok but the submit element lets you say you have more than one.

Erik: Then you create a submission.

John: I'm not necessarily against it. The form element

Leigh: Aren't we automating the past? We heard from Nick and Mark that people are not doing a lot of work using form/@action but the libraries in Javascript instead, and the behaviors emerging from that may be a better target.

Erik: I see the power of XForms as a way to make bigger forms, not for small form authors.
...

Leigh: I don't see the attributes added to HTML4 necessary to add to core XForms.

Mark: How about an XHTML1.1 module of attributes from XForms?

Charlie: That's what we're proposing but a twist, an XHTML1.1 module, not an XForms module.

leigh: it's a key difference, not a twist.

Charlie: Then we get 40% of the way, as Leigh says, and step back and see if we want to incorporate some of that back into XForms, but that document is a formal work product for us for our charter.

Mark: My proposal was to have a series of modules for XHTML11, not just one module. One for submission attributes, one for message, etc.

Erik: Should we be using the webforms attribute names?

Mark: If they make sense, but the issue is there is an underlying model and MVC and dependency graph in XForms and webforms has this work with events and elements talking to each other.

Charlie: So can we agree to produce the XHTML modules?

Nick: We agreed in Raleigh.

Charlie: That was modules for XForms.

Nick: There is still work, which Mark did, but no concrete module.

John: There is the syntax example for PO.
... Now we have more clarity and can turn that into a module.

Mark: Sticking with something smaller, submission attributes and message. name and others bring more stuff. Just get one module out, a smaller one.

John: We spent a fair bit of time yesterday...we went through the submission attributes. Some were associated with submission, and some were validity, data, etc modules.
... So you could have submission without data.

Charlie: We have that yesterday.

Mark: So that would be perfect for XHTML.
... We could have an XHTML modularization module with several attributes, no ref.

Charlie: We did that yesterday for XForms; we can use it on XHTML. Then we go on and do another one.

Mark: Not in the same module.

Charlie: Yes.

John: Does wrap up mean a rec-track document?

Leigh: Yes, that's what Mark is saying.

Mark: Role is a good example; it started with Raman and Steven, but then we added RDF, and then Shane got involved for modularization. Now they put in HTML5. they have their own specification. So when things are small enough and nimble they're more easily adopted.

Erik: I have a question about the XHTML module. One issue is providing the module. Another is adding the ramping up, submission elements, repeat, model, etc. Where do we say how this is glued together?

Mark: If you follow xhtml modularization each spec has to say something about the glue.

<wellsk> much better

Mark: So maybe we should just pick the uncontroversial attributes, the ones you did yesterday.

Charlie: We scrubbed the modelness out of it.

John: We created the map in the wiki. We'll have to start the work party to create this module, and then there's changing core xforms to be more like the map we've created.
... Having that module fully developed would be helpful. We saw the XHTML2 modularization and bits look like what we've done in XForms spec. It would be good to have that module written here this week.

Mark: We can use the role attribute as a model.

John: Is it in SpecXML?

Steven: no.

<Steven> It is in ShaneML

Erik: We have three attributes from wherever; what about xforms submission? Does that stay ? Does it get imported into HTML?

Mark: I believe so. Then it can be imported into SVG, as in the backplane.

Erik: We use terms such as driver or aggregator; it's pretty clear we're going to have that for XForms 1.2. Now we need another one for integrating.

John: For leaf nodes like role, it wasn't very hard. For submission module, there's a group of attributes and child elements that define core submission. if you want to use submission in combination with relevance, validity, or instance module, then you more modules.
... So you need it seems a higher-level module that pulls together relevance, validity, instance and submission, and then the adds the elements. Erik points out this happens on the XHTML2 side and we can't create a half-dozen specs and see how to combine three of them without another spec.

Mark: In the HTML world it doesn't us ethe same data model (submission) . It's not obviously hierarchical. One problem is that we've used the same attribute name to do different things.
... Let's say ref was used to bind to the data model. So ref on a div or span or svg doesn't matter.

Charlie: We wanted to avoid the submission module knowing about refs.
... There's a tipping point; at some point you need a place to put that logic.

Erik: That's what I had in mind for the small modules. But what about html input name? We want a flat XML document; we redefine or recast existing things.

John: Those are prose descriptions.

Erik: Then if we include this module, input name creates this data model in the background.

Mark: Submission doesn't care about its data model.

Erik: It assumes it's a data model.

Mark: It's capable of transmitting XML but it can do other things.

Erik: It's not JSON, it's XML.

Mark: We don't have a submission module, but if we did, it wouldn't start with XML. It would start with "something"

Paul: In that sort of module, where do you see relevance and validity? That's about submission?

John: This afternoon we should have the work jam where we look at the module breakdown.

Erik: It seems like a huge amount of work to make submission work with arbitrary data models. We tried that and stopped.

Mark: You want to be explicit about the values in attributes, the names of events, and where they occur, but leave open what's transmitted.

Erik: I can see ideally having that goal. Is it a goal of this group to handle json? If it's a sentence or two, that's fine.
... When we looked at IDL for the data module, we found we'd have to write an XPath API and that wasn't our job.
... And it's not clear that an XPath API is suitable for a JSON data model anyway.

Paul: Can we consider submission and serialization as two separate modules?

Erik: Does this group need to worry about JSON and YAML and everything? In theory we could break up submission into many parts, based on the lifecycle.

Mark: I like Erik's hierarchy description. In theory there could be a markup version of javacsript submission. It's no tour submission because it doesn't do validation, etc. Erik asks if it's our place to define it, but it seems useful for ourselves.

Erik: Just the time and energy.

Charlie: We factored out data model yesterday. Another pass could factor out serialization.

Erik: I just think it's a lot of effort.

Mark: It would be for adoption.
... Having a markup version of XHR doesn't solve any particular problem, but it begins to chip away at non-standard languages and you get XForms in many places.

Erik: People take what is working and use it, like Dojo.

Charlie: Yes, but people with experience with things like dojo find complexity and want to look for something up a level. It's not an XForms pure play either.

Erik: XForms has complexity as well: we need dialogs, model packaging, etc. Providing submission to others doesn't solve my problems.

Charlie: People will pick up on Flex and Silverlight as pure plays, but I don't see Xforms as a viable competitor unless we have an way to get started.

Erik: XForms does well for forms. I'm not sure Silverlight and Flex are good for forms.

Mark: I'm not sure that's competition. I saw someone with their own framework for text for help, etc. All done in PHP.
... He could have used less PHP and more Dojo, but then he'd have to commit. A standard language would help isolate that.

Charlie: I'm surprised to hear that rich web app pure plays are not competitors.

Mark: It's the architecture. When we've got these architectures going, we can be the onramp for silverlight.
... Flex is different because it is the entire thing.

Erik: Every language is getting bigger and looking for things like namespaces. Calling a submission declaratively in Javscript doesn't solve it for me. I'd rather see help for complexity.

Mark: I agree; src for model is something I've talked about.

John: Why did you boot it out of 1.2, nested modules?

Erik: The whole 1.2 thing isn't it for me.

Leigh: It's natural that Erik would have different interests because he has immediate customer needs, and Charlie is worried about the strategic issue of adoption.

Erik: I'm concerned about all the time I see on modularization and it's not something I want to work on.
... Who here wants to work on HTML compatibility?

John: I agree with Mark that we want more customers.

Erik: Maybe you're achieving this with ubiquity.

John: It's one solution proposed. There were two main complaints about xforms: browser availability and authoring ability.

Erik: Simplification is great.

John: It's a pre-sales problem.

Leigh: I think at this point in the WG life, after 10 years, we should be standardizing implementations based on implementation experience, not working forward from spec XML by committee to start with implementations. If you want a message module, make a message module implementation and show that it works and we'll write the document.

Erik: XProc is moving forward in this way.

John: We're supposed to be the next generation of web forms. We have a different problem. We have a whole bunch of implementations of web forms. All we're trying to do is tease apart the thing we have. It's like a failure of object orientation. Rather than figuring out what we're doing, we add three more variables. It seems like less of a crime every time until you suddenly end up with a class with 20,000 lines and 300 variables.
... You spend a year and a half trying to modularize everything.

Erik: I don't have that problem. I have the problem of 10,000 line forms.

John: So you don't have modularization within the form.

<Steven> prb is Paul Butcher, webBackplane

<nick> https://na1.connect.acrobat.com/orbeon

<nick> scribe: nick

<John_Boyer> http://lists.w3.org/Archives/Public/www-forms/2008Jun/0001.html

Review of XML Http Request

MarkB: Reading the spec it looks like they are documenting the current implementations in the current Browsers (based op the MS version)
... Our comments can't be 'they should add event X'
... We should comment on problems that prevent us re-using the spec
... They depend on HTML5 and the Window object which is a problem for us to reuse it
... We should sent a positive response asking to remove the unnecessary dependencies
... We should use it in future versions
... They are already thinking about future versions of the spec
... We should give input on it

Charlie: We shouldn't have a one on one mapping if they add events, we could wrap their events
... Do you think their dependency on window or HTML5 is political

MarkB: I think so
... We should say it is good, but the spec should be the object itself. The instantiation should be in the spec that uses this spec

Leigh: They can give an abstract spec and add a javascript binding

MarkB: They depend on HTML5 because window is defined in it

John: LC period is over, but the HTC gave us an extension, so we have to report soon

MarkB: I can do it today

<scribe> ACTION: MarkB to respond by Friday 13 June with our comments for Review of XML Http Request [recorded in http://www.w3.org/2008/06/11-forms-minutes.html#action01]

<trackbot> Sorry, couldn't find user - MarkB

John: You want to send some comments on the base URI?

MarkB: Yes, the request uses the security using the domain. If we decouple it we want to be more flexible, we want to give the base URI when we create the object used for the security

John: Isn't it a security problem?

MarkB: It could be read-only in a browser environment?

John: Do you not always have a containing document, which provides the base URI

Uli: Server side javascript

John: OK

MarkB: In sidewinder ....
... Explains how a relative URI is resolved in an XML application

Review of XML Events 2

http://www.w3.org/TR/xml-events2/

http://lists.w3.org/Archives/Public/public-forms/2008Jun/0017.html

Charlie: Most is editorial, the spec is overall good

http://www.w3.org/MarkUp/2008/ED-xml-events-20080604/

Charlie: introduction section
... The text isn't up to date with Event flow in DOM3

John: The actual diagram still lets me believe that capture goes to the target, which isn't the case

MarkB: XML events 2 is based on DOM 2 events
... (differences between DOM 3 events and DOM 2 events, groups, hierarchy)

John: The abstract states DOM level 3 events

MarkB: When we wrote this DOM level 3 didn't had three phases

John: DOM level 3 clearly states that capture doesn't goes to the target

MarkB: There is a flag atTarget in DOM level 2 events
... DOM level 3 has a notion of a third phase, this is a problem

John: The target phase of DOM level 3 is bubble and atTarget in DOM level 2

Charlie: Should we request an other version that is based on DOM level 2

Steven: XML events is just a syntax

MarkB: We should send a comment that DOM level 3 is required, DOM level 2 should be enough

John: I would have hoped that events could flow between different documents without changing the phase
... At the cut point the event goes in target phase, this is a problem

MarkB: This is well documented in XBL
... He has the notion of forwarding, but you don't need it you can also hide it
... We do this a lot with HTML events

John: Is it available somewhere else then in XBL

MarkB: NO, maybe it should be in XML events 2

John: I think so

MarkB: Add it to the comment we send

Charlie: Are you allowed to listen for events in another DOM tree?
... talking about remote handlers and remote observers

Leigh: XML events just specify that it is just id, does it requires to be in the some DOM, can't we just add an extra attribute
... The resolving can be taking care of by the language

MarkB: Observer should be a URI i think
... You should treat as an identifier

Steven: It is a security issue

MarkB: This can be handled by the engine

John: In XForms we have a sandbox of DOMs
... We send xforms-insert and xforms-delete to the instance element not the node because it is in a different DOM tree
... You should be able to say which dom

Charlie: you should be able to use XPath to address

Paul: XPointer

MarkB: I wonder if we can turn everything in XPointer and be backward compatible
... for observer and ...

Charlie: I have a couple of other editorial comments

<John_Boyer> It has also been a problem that ev:target was an ID

<Steven> How was that a problem John?

<John_Boyer> This is the context for MarkB's comment about turning everything into an XPointer

<John_Boyer> It is a problem because

<Steven> Oh I see

<Steven> Just being able to locate elements without an ID

<John_Boyer> if I want to observe an event on repeat element but don't want to set it up as a child of repeat

<John_Boyer> then I have to use ev:target with ID to indicate the repeat

Paul: Aren't they classified by name

MarkB: But then you need to know all events in front

Charlie where done

Leigh: Are you going to clarify how ID resolution is done in XML events 2

MarkB: Itis section 6 after the editors note

Paul: How is the context node found?

MarkB: There isn't one

* break

Review of CURIE

http://lists.w3.org/Archives/Public/public-forms/2008Jun/0019.html

John: Can we send this response

Leigh: Should I sent it, or could you do it

John: You can do it?

<John_Boyer> http://lists.w3.org/Archives/Public/public-forms/2008Jun/0014.html

Determine relationship of encoding, charset and SOAP

John: Paul can you help us?

http://lists.w3.org/Archives/Public/www-forms/2007Mar/0060.html

http://www.w3.org/MarkUp/Forms/2007/XForms-11-Schema.xsd

XForms Schema data-types

Discussion about empty strings

MarkB: It is a hack to allow the empty string in the schema data types
... We should create emailOrEmpty

John: We decided a long time ago that the xforms data-types should include the empty string

MarkB: What is done is done, we can't do much about it

Leigh: It is already decided
... We can do that with minOccurrence

MarkB: it doesn't apply on list, a list can be empty

Leigh: OK, then we don't need to change it

<smaug> Has anyone gone through the comments I sent over a year go about XML Events 2 http://lists.w3.org/Archives/Public/www-forms/2007Feb/0093.html http://lists.w3.org/Archives/Public/www-forms/2008Jan/0000.html ?

<Steven> Hi Smaug, who are you?

<Steven> Ah, Olli Pettay

MarkB: It looks that a list can't be empty and that min and max occurrences applies on it
... minLength can be applied on list (this is what we need)

<smaug> Steven: right

<smaug> I think the problem mentioned in the latter email is fixed

<smaug> but not the problems mentioned in the first one

<Steven> It looks like you sent the comments to the wrong list Smaug

<smaug> oh

<Steven> should have been www-html-editor

<smaug> well, I sent those to markb too

<markbirbeck> http://www.w3.org/TR/2004/REC-xmlschema-2-20041028/datatypes.html#datatype-components

<markbirbeck> "Any property identified as a having a set, subset or ·list· value may have an empty value unless this is explicitly ruled out: this is not the same as absent."

<Steven> true, but www-html-editor mails get forwarded to the issue tracker

<markbirbeck> So listItems can already be empty.

So listitems allows the empty string

John: listitem doesn't allows the empty string, but if the group thinks we can keep it like it is

Submission @resource comment to RDFa

http://lists.w3.org/Archives/Public/public-forms/2008Apr/att-0132/2008-04-30.html#ACTION1

John: MarkB I want to make sure that we still believe that it just a comment to RDFa and we don't have not to change anything

MarkB: As far as the RDFa group there is no problem
... There is no behavior consequence in RDFa for the resource attribute

John: Maybe there is nothing to say about it
... So it is done

<smaug> Steven: should I resend the comments to www-html-editor?

*meeting ends

- DRAFT -

Forms FtF, Amsterdam, Day 3

11 Jun 2008

Attendees

Contents