See also: IRC log
<scribe> scribenick: klotz
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
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
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
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
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
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
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
This is scribe.perl Revision: 1.133 of Date: 2008/01/18 18:48:51 Check for newer version at http://dev.w3.org/cvsweb/~checkout~/2002/scribe/ Guessing input format: RRSAgent_Text_Format (score 1.00) Succeeded: s/src/resource/ Succeeded: s/hte/the/ Succeeded: s/lines/lined/ Succeeded: s/us /use / Succeeded: s/iwth/with/ Succeeded: s/tey/they/ Succeeded: s/ hte / the /G Succeeded: s/* Lunch// Succeeded: s/Topic/TOPIC/ Succeeded: s/evenets/events/ Succeeded: s/DOM/DOM tree/ Succeeded: s/threat/treat/ Found ScribeNick: klotz Found Scribe: nick Inferring ScribeNick: nick ScribeNicks: klotz, nick Present: Charlie John Erik Leigh Nick Rogelio Rafael Steven Keith(remote) MarkBirbeck PaulButcher Regrets: MarkS Agenda: http://lists.w3.org/Archives/Public/public-forms/2008Jun/0014.html Got date from IRC log name: 11 Jun 2008 Guessing minutes URL: http://www.w3.org/2008/06/11-forms-minutes.html People with action items: markb[End of scribe.perl diagnostic output]