Forms WG FtF, Madrid Spain, Day 2 of 3 -- 13 Sep 2007

<Steven> Day 1

<Steven> Scribe: Steven

XPath function issues

http://htmlwg.mn.aptest.com/cgi-bin/xforms-issues/XPath?id=147;user=guest;statetype=1;upostype=-1;changetype=-1;restype=-1

Issue 147

[on] yes

<markbirbeck> [up] thanks

<Nick> http://www.w3.org/TR/xquery-operators/#func-seconds-from-dateTime

http://www.w3.org/TR/xpath-functions/#func-seconds-from-dateTime

John: This is a long-standing xforms function
... So we should say the same thing, that we will look into this when we move to XPath 2.0

<Nick> http://en.wikipedia.org/wiki/Leap_second

Charlie: There are both negative and positive leap seconds, added pretty much at random
... on average once every 18 months

John: We shouldn't support them, too hard

<Nick> http://java.sun.com/j2se/1.4.2/docs/api/java/util/Date.html

[General agreement]

Charlie: What if you implement with a Java that does support leap seconds?

Steven: Then it is an incorrect implementation

RESOLUTION: No name change, no leap seconds for seconds-from-DateTime

John: And the same again for seconds-to-DateTime

<scribe> ACTION: jboyer to implement seconds-to/from-dateTime changes [recorded in http://www.w3.org/2007/09/13-forms-minutes.html#action01]

<trackbot-ng> Created ACTION-402 - Implement seconds-to/from-dateTime changes [on John Boyer - due 2007-09-20].

Issues with date-time functions

Issue 12

http://htmlwg.mn.aptest.com/cgi-bin/xforms-issues/XPath?id=12;user=guest;statetype=1;upostype=-1;changetype=-1;restype=-1

http://www.w3.org/MarkUp/Forms/2006/xforms-for-html-authors-part2.html

[Long discussion about whether now() returns the local time or not; Steven claims the current text means it should return the local time, and the timezone is normalized to UTC]

Erik: There are three scenarios
... local time with tz info
... local time without tz
... utc

John: Some of us thought that now always returns a UTC time
... and some thought it returned the locl time with tz info
... there is a use case for both

Steven: You can calculate the UTC from the local+tz, but not the other way round

John: This is a good instance of where an example would have made everything clearer

http://books.xmlschemata.org/relaxng/ch19-77049.html

Steven: You'll see that xsd:datetime always returns the timezone info as +/- hh:mm

<unl> http://www.w3.org/TR/xmlschema-2/#dateTime

<unl> chapter 3.2.7.2 Canonical representation

<markbirbeck> How about now() returns the local time...

<markbirbeck> ....now(0) returns UTC time.

<markbirbeck> ...now(-8) returns time 8 hours behind UTC...

<markbirbeck> ...and so on.

<markbirbeck> Then we don't have to muck around normalising strings, and stuff. It's a real pain, and usually requires script. :)

<John_Boyer> This is not too different from saying now() returns UTC and local-dateTime() returns the other stuff

<markbirbeck> I've just checked our implementation and we return the *time* normalised to UTC, I'm afraid.

<markbirbeck> I agree with Steven that a close read of the spec would have us only normalise the time-zone, but unfortunately that's not the way it has been done. :(

<John_Boyer> Nick: so 40 minutes off an hour would be now(-7.666666666...)

Well, I'm checking implementations now

I haven't found one that disagrees yet

<markbirbeck> On my system formsPlayer is returning 2007-09-13T09:44:00Z...but I've set my system time-zone to be somewhere in cenral Russia.

<markbirbeck> In other words, the time has been normalised to UTC, not just the time-zone.

Erik: There are two options: change now, or leave now and add a new function

John: If we leave now, we still have to have a parameter to say what we want

Steven: XSmiles, Novell and Mozilla use the +02:00 form

John: Proposals 1) Now always returns Z
... and use localDateTime

2) add param to now(), remove localDateTime

<markbirbeck> The problem is that the current definition refers to "the current system time". Since that is not something that we have defined anywhere, then you cannot assume that the "current system time" == "local time".

3) Add param to now(), make default be local and remove localDateTime

Steven: 4) now() produces tz version, and add a function utc()

John: 5) now() returns local + tz and no other functions

<John_Boyer> Just ran out of time for this set of issues

<Nick> a string value in the canonical XML Schema xsd:dateTime format.

<John_Boyer> Mark, I think you also missed the part of the discussion about "canonical" representation

Mark: I think our (formsPlayer) reading of changing the time is the right one

<John_Boyer> which further supports what you just said

<Charlie> in schema

<Nick> http://www.w3.org/TR/xmlschema-2/#dateTime-lexical-representation

<Nick> --> you can only return zulu time

<unl> spec says _canonical_ representation http://www.w3.org/TR/xmlschema-2/#dateTime-canonical-representation

<ebruchez> I agree 100% with Mark

<John_Boyer> me too

<Nick> http://www.w3.org/TR/xmlschema-2/#dateTime-canonical-representation

[John does a straw poll around the room about which of the solutions we should adopt]

<John_Boyer> Mark, which of the 5 above best reflects you

Erik: I don't think that is good, but it agrees with what XForms 1.0 says

Steven: Which I think is wrong, since the *intention* was the localtime+tz version
... (and which several implementations, but not all, do)

Mark: I think now() returning what Steven wants is more useful
... but I don't like the idea of the spec changing to reflect that
... I think solution 2) above is best

<John_Boyer> 1) was actually clarify now() as well

John: Can people live with solution 1)

Uli: I can live with 1)

<markbirbeck> As a general point, I don't think "changing the spec to what we _meant_ to say, rather than what we _did_ say" is a good strategy at this stage in XForms' life. :) Sometimes we just have to live with our mistakes.....

Steven: What can I say?

<John_Boyer> yes?

<John_Boyer> Mark, can you live with #1

<John_Boyer> which we already have

<John_Boyer> Steven's now() is the 1.1 LC spec's local-dateTime()

Erik: I think that the real right way is to to go the XPath 2.0 route

Steven: I think solution 1 is the best of a bad bunch

<John_Boyer> Proposed Resolution: Clarify that now() returns Z time only and add examples, keep local-dateTime()

Mark: The reason that the param version is handy is for doing timezone calculations

<John_Boyer> RESOLUTION: Clarify that now() returns Z time only and add examples, keep local-dateTime() and add examples that juxtapose to now()

<John_Boyer> ACTION: jboyer to Clarify that now() returns Z time only and add examples, keep local-dateTime() and add examples that juxtapose to now() [recorded in http://www.w3.org/2007/09/13-forms-minutes.html#action02]

<trackbot-ng> Created ACTION-403 - Clarify that now() returns Z time only and add examples, keep local-dateTime() and add examples that juxtapose to now() [on John Boyer - due 2007-09-20].

RESOLUTION: Clarify that now() returns Z time only and add examples, keep local-dateTime() and add examples that juxtapose to now()

<markbirbeck> are you having a break?

<John_Boyer> yes

<Nick> http://www.w3.org/2002/09/wbs/35125/TPAC2007/

<John_Boyer> ACTION: John to address issue 65 [recorded in http://www.w3.org/2007/09/13-forms-minutes.html#action03]

<trackbot-ng> Sorry, amibiguous username (more than one match) - John

<trackbot-ng> Try using a different identifier, such as family name or username (eg. jkugelma, jboyer)

<ebruchez> back from the break

<ebruchez> scribe ebruchez

<ebruchez> back from the breakt then

<ebruchez> scribe: ebruchez

Issue 12

<John_Boyer> http://htmlwg.mn.aptest.com/cgi-bin/xforms-issues/XPath?id=12;user=guest;statetype=1;upostype=-1;changetype=-1;restype=-1

John: I think that resolution is XForms processor get tz info in an implementation-specific way

Charlie: Right

<John_Boyer> Proposed Resolution: Respond to issue 12 by saying that the method by which the XForms processor gets the timezone info from the user agent is not specified because it is an implementation defined.

John: Anybody objects?

Charlie: Should be "implementation-specific".

<Steven> Mark, I just tried FormsPlayer on now(), and it gets it wrong. It says (for me) 2007-09-13T10:46:31Z, but it is now 9:46Z

RESOLUTION: Respond to issue 12 by saying that the method by which the XForms processor gets the timezone info from the user agent is not specified because it is implementation-defined.
... Respond to issue 12 by saying that the method by which the XForms processor gets the timezone info from the user agent is not specified because it is implementation-defined.

Issue 11

<John_Boyer> http://htmlwg.mn.aptest.com/cgi-bin/xforms-issues/XPath?id=11;user=guest;statetype=1;upostype=-1;changetype=-1;restype=-1

John: Felix is asking us to decide what we just decided earlier.

Charlie: What if there is no tz info available?

Hi Keith

<wellsk> Hi

discussing now http://htmlwg.mn.aptest.com/cgi-bin/xforms-issues/XPath?id=11;user=guest;statetype=1;upostype=-1;changetype=-1;restype=-1

Erik: I think XPath 2.0 says there is always tz information in the context.

John: He is asking we require UTC when there is no tz info.

Erik: What does it mean to be not available?

John: My cell phone doesn't have tz info.
... He is just saying that he thinks the result may not have a Z in the end.

Erik: The text is already there.

<John_Boyer> Proposed Resolution: Accept 11. Instead of implementation default when no tz info available, it should return the time followed by Z, which is the canonical form.

Erik: Not sure I understand this.

<John_Boyer> When a device has time of 12:00 but no tz info, the result is 12:00Z

<John_Boyer> So, UTC is the default when no tz info available

<John_Boyer> Need Z to be in canonical form

Erik: Ok get it.

RESOLUTION: Accept 11. Instead of implementation default when no tz info available, it should return the time followed by Z, which is the canonical form.

<scribe> ACTION: jboyer to change the text in 7.10.1 to specify that instead of implementation default when no tz info available, it should return the time followed by Z, which is the canonical form. [recorded in http://www.w3.org/2007/09/13-forms-minutes.html#action04]

<trackbot-ng> Created ACTION-404 - Change the text in 7.10.1 to specify that instead of implementation default when no tz info available, it should return the time followed by Z, which is the canonical form. [on John Boyer - due 2007-09-20].

Issue 63

<John_Boyer> http://htmlwg.mn.aptest.com/cgi-bin/xforms-issues/XPath?id=63;user=guest;statetype=1;upostype=-1;changetype=-1;restype=-1

Erik: Can't you use a type instead?

Steven: No you need to do a calculation.

<John_Boyer> Proposed Resolution: Accept 63. Change ID-card-number to card-number and change luhn() to card-number()

<markbirbeck> Could we follow the pattern that is emerging in other functions where we indicate the type of calculation to perform? card-number("luhn")....card-number(@type)....and then card-number() defaults to "luhn"?

Nick: What about XPath 2.0, won't you be able to use "castable as"?

Erik: This would have to be an extension type over XPath 2.0. Not sure how that will work.

<John_Boyer> Proposed Resolution: Accept 63. Change ID-card-number to card-number and change luhn() to is-card-number()

John: So there can't be a conflict with XPath 2.0, right?

Erik: I don't think so.

<John_Boyer> RESOLUTION: Accept 63. Change ID-card-number to card-number and change luhn() to is-card-number()

<scribe> ACTION: jboyer to change ID-card-number to card-number and change luhn() to is-card-number() [recorded in http://www.w3.org/2007/09/13-forms-minutes.html#action05]

<trackbot-ng> Created ACTION-405 - Change ID-card-number to card-number and change luhn() to is-card-number() [on John Boyer - due 2007-09-20].

<scribe> ACTION: nick to change XForms schema to change ID-card-number to card-number [recorded in http://www.w3.org/2007/09/13-forms-minutes.html#action06]

<trackbot-ng> Created ACTION-406 - Change XForms schema to change ID-card-number to card-number [on Nick Van Den Bleeken - due 2007-09-20].

Issues 6 and 10

<unl> http://htmlwg.mn.aptest.com/cgi-bin/xforms-issues/Types?user=guest;selectid=6;statetype=-1;upostype=-1;changetype=-1;restype=-1

<unl> http://htmlwg.mn.aptest.com/cgi-bin/xforms-issues/Types?id=10;user=guest;statetype=3;upostype=-1;changetype=-1;restype=-1

John: Charlie asked to clarify lexical vs. value space.

<John_Boyer> 28<http://htmlwg.mn.aptest.com/cgi-bin/xforms-issues/Types?user=guest;selectid=6;statetype=-1;upostype=-1;changetype=-1;restype=-1> rnhttp://www.w3.org/TR/xmlschema-2/#defn-validation-rules

<John_Boyer> http://www.w3.org/TR/xmlschema-2/#defn-validation-rules

John: This part of the spec is very interesting. Value space vs. lexical space. E.g. concept of "one hundred": could be represented as "100" or "1E2".

<Steven> or "0100"

Charlie: What about what's displayed on the screen for the user?

John: It's a display value. Different from lexical value.
... Constraints are only on value and lexical space.
... So going back to schema 4.1.4, you see that validity tackles lexical space and then the value space. Interesting part is "pattern valid", which applies to the lexical space.

Erik: Pretty clear that patterns apply to the lexical space.

John: To get back to email, it's perfectly legitimate for UI to allow i18n characters, and then boil them down to a valid lexical space for the email type.
... Question is do you need i18n characters in the lexical space.

Nick: What if you have "e acute"?

John: The XML contains stuff in the lexical space.

Nick: In my example, you won't put "e acute" char in the instance.
... What about putting a constraint?

Steven: It's the task of the emailing app to convert.
... Who does the conversion, the XForms control, or the email sending app.

Charlie: We understand the distinction, but now we need to define the lexical space.

<Steven> http://en.wikipedia.org/wiki/Punycode

Erik: We are not the first ones to do this, right?

John: Currently, our pattern implies that the UI does the conversion.
... If we change that, then how do we convert this for the mailto: protocol?

Erik: What about HTML forms, how do they use it?
... Also see human-readable resource identifiers, idea is to convert from human-readable representation.

John: I think we should defer to a future version of XForms.

Nick: But if we don't allow "e acute" now, and defer that to the control, then constraints are hard to calculate, and next version of XForms won't be compatible.

John: We could define two different types to solve the issue of compatibility, e.g. email-rfc2822

Nick: But it's not author-friendly.

Steven: What's the problem?

<John_Boyer> http://www.ietf.org/rfc/rfc2822.txt

<Steven> http://en.wikipedia.org/wiki/Punycode

<Steven> ignore that

<Steven> http://www.ietf.org/internet-drafts/draft-ietf-eai-utf8headers-07.txt

<Steven> is what I meant

John: But we need to get XForms 1.1 out.

Uli: It would be ok for me to take the email type out.

John: We could just say that the email type is a string without constraints.
... But when do we care about validation? Server-side may not have xforms:email.

Erik: But when we lose over half of the email feature.

Steven: Some site validate emails wrong. The idea here was to get validation done right.
... I just want the feature to help with email validation. I have a "+" in my address and it fails very often.

<Steven> http://www.ietf.org/rfc/rfc4952.txt

Steven: RFC for i18n email not ready yet.

Steven: It doesn't seem that we have a spec we can use as inspiration.

<John_Boyer> RESOLUTION: Defer issue 10 to future xforms where i18mail can be defined and keep current pattern definition of xforms email.

<John_Boyer> ACTION: Nick to respond to issue #10 according to resolution to defer i18mail to future and keep current pattern for xforms:email in 1.1 [recorded in http://www.w3.org/2007/09/13-forms-minutes.html#action07]

<trackbot-ng> Created ACTION-407 - Respond to issue #10 according to resolution to defer i18mail to future and keep current pattern for xforms:email in 1.1 [on Nick Van Den Bleeken - due 2007-09-20].

Issue 6

<John_Boyer> http://htmlwg.mn.aptest.com/cgi-bin/xforms-issues/Types?user=guest;selectid=6;statetype=-1;upostype=-1;changetype=-1;restype=-1

<Steven> http://htmlwg.mn.aptest.com/cgi-bin/xforms-issues/Types?id=6;user=guest;selectid=6;statetype=-1;upostype=-1;changetype=-1;restype=-1

John: Issue is we don't explicitly define the lexical space vs. value space.
... In schema, for each type, you have value space, lexical space, and canonical version. We don't do that.
... See 5.2.2, which also seems to confuse lexical vs. value space.

Steven: Why do we care about lexical again?

John: Because that's what validation will look at.
... With the XForms types, we really care more about the lexical space.

Steven: They why do we care about value space?

John: My point.

Steven: (discussing value and lexical space for boolean type)

Nick: Issue is you don't want to require a conversion function for card numbers, for example.

Steven: My basic grudge is we are nicer to machines than humans.

Erik: Users don't enter in the XML, they do it through controls.

Nick: (example of dateTime control)

John: Implementations should provide convenient means.

Erik: UI for credit card numbers almost always never allow you to enter dashes or spaces. So the lexical space should not have them. But the control can be fancier and allow dashes and spaces.

John: Issue 6 is already accepted. But I think that my action item should say that we are clearer about the lexical space of the data types and replace the older action item.

<Steven_> Sorry Mark, I pressed fn-f4 instead of ctrl-f4

RESOLUTION: We clarify the lexical space of all the XForms data types, and we link to lexical space definitions in 8.1.1.

<John_Boyer> ACTION: jboyer to clarify the lexical space of all the XForms data types, and we link to lexical space definitions in 8.1.1. [recorded in http://www.w3.org/2007/09/13-forms-minutes.html#action08]

<John_Boyer> lunch time

<trackbot-ng> Created ACTION-408 - Clarify the lexical space of all the XForms data types, and we link to lexical space definitions in 8.1.1. [on John Boyer - due 2007-09-20].

<John_Boyer> restarting

Demonstrations

<John_Boyer> SATEC will be giving a demonstration

<John_Boyer> SATEC is doing a demo now

<Steven_> <datamovil><xforms/><lookblock/><layoutblock/><mediablock/></datamovil>

<Steven_> No schema, no namespaces, no scripting, model-driven switch,

<Steven_> docs are multi-screen

<Steven_> ext libs may be inlcuded via plugins

<John_Boyer> mini host language with architecture similar to ODF.

<John_Boyer> Core XForms in an xforms tag

<John_Boyer> UI controls associated with layout elements using ID attrs

<Roger> DataMovil has some examples as JavaPetStore

<Roger> Rafa: is going to present the first application

<John_Boyer> DataMovil supports lots of different mobile devices

<Roger> Rafa: is trying to project the application

<Roger> Rafa: We can see the first menu, where we can see what apps are available

<Roger> john: Are the apps xforms?

<Roger> Rafa: Yes

<John_Boyer> DataMovil provides an application mgmt. Each app deployed to the system is an XForm

<Roger> Rafa: The first window you can chose the category

<Roger> Rafa: first window is based in Dynamic Expressions

<Roger> Rafa: Second window, we can see the shopping cart, based in a repeat

<Roger> Rafa: Also uses insert 1.1

<Roger> Rafa: We add to the shopping cart two items a cat an a dog

<Roger> Charlie: cat is really cheap

<Roger> Jboyer: what the navigation buttons are based in

<Roger> Rafa: outside of the xforms engine

<Roger> Rafa: we can see the process speed difference between computer and PDAs

<Roger> Jboyer: do you use submit?

<Roger> Rafa: I use a trigger + send action

<Roger> Rafa: I�m going to show you the app designer

<Roger> Rafa: Here you can see the editor

<Roger> Rafa: Select1, groups

<Roger> Rafa: we can see inline the changes we apply to the xform app

<Roger> Rafa: here is the source code

<Roger> Charlie: Can you show an example about the link between the layout or look with the controls

<Roger> Charlie: It�s interesting xforms controls point to presentation information

<Roger> Rafa: Switch uses a boolean expression, we don�t use the toogle

<Roger> Rafa: Here is the look and layout

<Roger> Rafa:We can download an image and saved locally

<Roger> Rafa: in order to uses it in the future

<Roger> Jboyer: Can you show the repeat?

<Roger> Rafa:I find the repeat

<Roger> Rafa: Repeat includes also links to layout a look

<Roger> Jboyer: is more or less css

<Roger> Jboyer: ... is the layout a kind of flowlayout

<John_Boyer> layout and look attrs are like css styling to connect xf controls to prsentation

<Roger> Rafa: it�s relative

<Roger> Rafa: we have some attributes

<Roger> Rafa: we have some presentation information implicit

<Roger> Nick: we use appearence

<Roger> jboyer: you want to say host language do it in this way

<Roger> Rafa: you can�t launch to instances of the client

<Roger> Rafa: We copy or stored the actual state

<Roger> Rafa: (using session option) and after you can restore the form from that state

<Roger> Rafa: ... the result of a submission it�s a new document

<Roger> Rafa: we support a submission history, I mean you can go back the last document

<Roger> Rafa: ... are going to show you a demo for a project we have right now

<Roger> Rafa: ... based in the bus tickets machine

<Roger> Rafa: ... the app I�m going to show you uses a xforms-ready in order to check one mIFare based card

<Roger> Rafa:... after the card is read

<Roger> Rafa: ...you can see the card data

<Roger> Rafa:... next screen shows the pass number, and the busdriver name

<Roger> Rafa:... number of passengers also

<Roger> Rafa: End of the presentation

<Roger> jboyer: you can give some pictures in order to show what devices supports the xforms

<Roger> Rafa: we have 10 references using this technology, some spanish

<Nick> maybe : /^\w[-.\w]*\@[-a-b0-9]+(?:\.[-a-b0-9]+)*\.(?:com|edu|biz|org|gov|int|inf

<Nick> rssagent, scribe?

<Steven_> grep scribe

<scribe> scribe: ebruchez

Issue 8

<John_Boyer> http://htmlwg.mn.aptest.com/cgi-bin/xforms-issues/Model?id=8;user=guest;statetype=1;upostype=-1;changetype=-1;restype=-1

John: Asks whether we can use IRIs fo rexternal schema locations

<Steven_> http://www.w3.org/TR/2001/REC-xmlschema-2-20010502/#anyURI

<John_Boyer> schema attr is list of xsd:anyURI

<klotz> RFC 3987 gives some guidance in 1.2 a, b, c

http://www.w3.org/TR/xmlschema11-2/

<John_Boyer> schema 1.1 redefines anyURI to allow IRIs

<John_Boyer> but we are not based on schema 1.1

Erik: Schema 1.1 draft now says anyURI includes IRIs
... Schema 1.1, as of the Feb 2006 draft, does not upgrade the namespaces for data types

http://www.ietf.org/rfc/rfc3987.txt

<unl> http://ietf.org/rfc/rfc3987.txt

<unl> 1.2.a says: For example, XML

<unl> schema [XMLSchema] has an explicit type "anyURI" that includes

<unl> IRIs and IRI references. Therefore, IRIs and IRI references can

<unl> be in attributes and elements of type "anyURI".

<John_Boyer> Proposed Resolution: Defer issue 8 to future version of XForms, which may be based on version of schema later than 1.0. XForms 1.1 is based on XML Schema 1.0 second ed., which does not appear to support IRI in xsd:anyURI type

http://www.w3.org/TR/2001/REC-xlink-20010627/#link-locators

John: Ok so we dot not support IRIs explicitly, but we support anyURI as defined in XML Schema 1.0. We can just respond that.

<John_Boyer> RESOLUTION: Defer issue 8 to future version of XForms, which may be based on version of schema later than 1.0. XForms 1.1 is based on XML Schema 1.0 second ed., which does not appear to support all IRIs in the xsd:anyURI type

Issue 13

<John_Boyer> http://htmlwg.mn.aptest.com/cgi-bin/xforms-issues/Model?id=13;user=guest;statetype=1;upostype=-1;changetype=-1;restype=-1

John: In the last call version of 1.1, we said that @src may come from the host language. Does this mean that IRI support is delegated to the host language?
... But since then, we reverted to not delegating @src processing to the host language. This is good because the processing of @src was not exactly like we wanted it.
... So response is that @src is back to XForms, and we follow XML schema 1.0's anyURI.

<markbirbeck> I have to go now.

<markbirbeck> Will join you all again tomorrow morning.

<John_Boyer> Proposed Resolution: Answer issue 13 as follows: "Due to other last call comments, src was moved from host language control to XForms, where it is governed by rules of xsd:anyURI from schema 1.0"

<markbirbeck> Have a good evening.

<John_Boyer> thx

<klotz> what about other places, submission resource for example?

<unl> leigh, all these are xsd:anyURI too

<unl> and they are not governed by the host language

<klotz> not being able to hear the discussion I can't tell whether I agree with the opinions, but that's a fact I agree with.

<John_Boyer> throughout our spec, it's xsd:anyURI, but the LC comment asks specifically about this case because it was the only case that involved host lang control

<klotz> so do we believe that we're prohibited from IRI support in xsd:anyURI until XML Schema 1.1? I don't believe that.

<John_Boyer> any objections to above proposed resolution?

<John_Boyer> any impl that runs xforms schema would choke

<John_Boyer> if IRI used chars not in lex space of anyURI

<klotz> what is the lexical space of anyuri?

<klotz> link...

<John_Boyer> above

<klotz> the lexical space is anything that can be urlencoded according to xlink?

<unl> leigh, it's unlear. http://www.w3.org/TR/xmlschema-2/#anyURI says: his means that a wide range of internationalized resource identifiers can be specified when an anyURI is called for, and still be understood as URIs per [RFC 2396], as amended by [RFC 2732], where appropriate to identify resources.

<unl> 'a wide range' is not all :-(

<klotz> 3.2.17.1 gives a pretty clear definition.

the question is whether that is equivalent to what is in the IRI spec

meaning exactly equivalent

<klotz> ah

<klotz> there's no reason we can't use 3987 to encode; xml schema merely uses xlink to specify the lexical space, not the processing model.

<John_Boyer> yes there is

<John_Boyer> schema 1.0 does not ref 3987

<John_Boyer> schema 1.1 does

<John_Boyer> but 1.1 is a WD

<John_Boyer> 1.5 years old too

<unl> and http://www.w3.org/International/O-URL-and-ident.html says: Various document formats already use IRIs:

<unl> * In XML 1.0, system identifiers are IRIs (see also erratum E26)

<unl> * In XLink , the href attribute is an IRI

<unl> * XML Schema provides the anyURI datatype for IRIs

<John_Boyer> not a recommendatoin

<John_Boyer> opinion of i18n team about what *should* be

<John_Boyer> in 2003

<John_Boyer> oops wrong one

<John_Boyer> objections?

<klotz> none other than the practical point that all serious implementations will support IRI's today regardless of what we say

<John_Boyer> http://www.w3.org/TR/2001/REC-xlink-20010627/#link-locators

<John_Boyer> Well, most IRIs are supported by this

<John_Boyer> Most serious design tools would have a problem with IRIs that violate the lex space

<John_Boyer> Leigh, can you live with above proposed resolution?

<klotz> yes, i said no objections other than to point out it's unlikely to have any effect on implementations.

<John_Boyer> RESOLUTION: Answer issue 13 as follows: "Due to other last call comments, src was moved from host language control to XForms, where it is governed by rules of xsd:anyURI from schema 1.0"

Topic 9

<John_Boyer> http://htmlwg.mn.aptest.com/cgi-bin/xforms-issues/Misc?id=9;user=guest;statetype=1;upostype=-1;changetype=-1;restype=-1

Erik: Nobody is really using XML 1.1, and it seems like it's a lot of work to ensure we support XML 1.1 correctly for XForms 1.1.

John: Future feature.
... Does XPath 2.0 support XML 1.1?

Erik: Yes, XPath 2.0 supports XML 1.0 or 1.1.

<John_Boyer> Proposed Resolution: Defer issue 9. In XForms 2.0 we plan to support XPath 2.0 , and could consider supporting XML 1.1 at that time.

<John_Boyer> RESOLUTION: Defer issue 9. In XForms 2.0 we plan to support XPath 2.0 , and could consider supporting XML 1.1 at that time.

Issue 38

<John_Boyer> http://htmlwg.mn.aptest.com/cgi-bin/xforms-issues/Misc?id=38;user=guest;statetype=1;upostype=-1;changetype=-1;restype=-1

Erik: (explains what HRRIs are about)

John: So Erik how would you like us to deal with this now?

Erik: It's not really an LC issue, we should just consider this for a later spec.

<klotz> BTW link on Norm's page to IETF draft is broken

<John_Boyer> Yes, change the 00 at the end to 01

<John_Boyer> the 00 version got expired

<John_Boyer> the new one is good till Nov. 2007

<klotz> TNX

Nick: But then our XForms schema will be harder to write since anyURI doesn't include HRRIs.

John: We are not saying we intend to support HRRI, but we may, so we should defer, not reject.

Erik: Author convenience IMO primes over the convenience of the XForms schema.

<John_Boyer> Proposed Resolution: Defer 38 to future XForms, which may consider supporting HRRIs after IRI support is added.

<klotz> +1

<John_Boyer> RESOLUTION: Defer 38 to future XForms, which may consider supporting HRRIs after IRI support is added.

<klotz> are we on nillable yet?

John: What about we skip to the MIP questions?

Issue 29

<John_Boyer> http://htmlwg.mn.aptest.com/cgi-bin/xforms-issues/Events?id=29;user=guest;statetype=1;upostype=-1;changetype=-1;restype=-1

John: I think we should defer
... There is what the MIP events do now, and what we would like them to do.
... Maybe we need other events. These come from the model. Not sure we can fix this from the model.

Nick: You only need to send them if there are listeners.

Erik: (explains again all the issues with MIP events)

Uli: Doesn't see a problem.

John: Repeat is an issue: repeat may be entirely replaced.
... Sure, we have an architecture flaw.

<unl> Erik, I do see problems, but I don't conclude that MIP events are broken or even useless.

John: You can also have a binding changes and the control values hasn't changed.
... (explains use cases)

<Steven> skype crashed Leigh; just a mo'

John: One use case that works is showing an ephemeral alert when a control becomes invalid.

Nick: Another use case is value change sending submission w/ instance replacement.

Charlie: What John says is that you need other events.

Nick: Then I don't see the use for these events.

Erik: Exactly my point.

John: We had a use case with a list of 1500 counties. Single list is too large, so you use dependent lists, one with state, the other one with counties.

Nick: (elaborates on that)

Uli: For instance replacement, we keep old MIP values.

Erik: This is similar to my proposal of doing everything from the control's perspective.

Charlie: I think we need both model and UI events.

Erik: If we have UI-centric events, I don't see why you need model-centric events.

Nick: We may need a rebinding/ rewiring event as well.

John: (showing demo of interest rate form)

Erik: Sure the events are sometimes useful, but they don't always work.

John: I agree.

Nick: For validity, the event should always be reliably dispatched.

John: I am proposing that this is a necessary XForms 1.2 update. But we need a fundamentally different architecture.

Charlie: Doesn't a rebind event solve this?

Uli: In Chiba, we don't care about rebindings, controls just keep their state and we dispatch appropriately.

John: I would like to see the the UI events proposed, and then the question asked the WG whether there are use cases where the current MIP events are needed. Then we can deprecate the curent MIP events in XForms 1.2, and remove them in XForms 2.0.
... It sounds like the architecture of the current MIP events is flawed, but maybe there are still use cases for the current MIP events.
... XForms 1.2 is about easier form authoring, so this could fit.

Charlie: I would like to see an event system to refresh controls then. It would encourage the separation between model and view.

John: xforms-refresh could in the end be just a notification event.

John, Uli: (agree that all this would be good)

Uli: Important problem is that the controls have to keep the state.

Nick: Any implementation where controls don't keep the state?

John: They keep the state, but this doesn't happen through events.

<John_Boyer> Proposed Resolution: Defer changes to MIP events for now because we really need a control-based design for events in a future version of XForms.

<John_Boyer> Proposed Resolution: Defer changes to MIP events for now because we need a broader based redesign of events for controls and possibly also for model.

<klotz> so MIP events still don't get sent on startup?

<John_Boyer> that's the proposal, yes

<klotz> ok, sounds ok with me. it's not what i want but it's what we're doing now and we have a plan to re-examine the whole thing later when inconsistencies can be resolved.

We try not to make further changes to MIP events until the new redesign is done.

<klotz> +1

<John_Boyer> RESOLUTION: Defer changes to MIP events for now because we need a broader based redesign of events for controls and possibly also for model.

Erik: Same topic, and I would prefer deferring to XForms 1.2 rather than fixing it wrong.

RESOLUTION: Defer changes to MIP events for now because we need a broader based redesign of events for controls and possibly also for model.

Issue 50

John: See resolution above.

Issue 176

<John_Boyer> http://htmlwg.mn.aptest.com/cgi-bin/xforms-issues/MIPs?id=176;user=guest;selectid=176;statetype=-1;upostype=-1;changetype=-1;restype=-1

John: There are some notes in the comments there. My idea is that properties are usually consumed by form controls.
... Is a non-relevant node changeable?

Nick: For me, relevant and readonly are different.
... The spec says something for readonly, not for relevant.

<klotz> I need to go. See you tomorrow.

John: Then readonly was maybe wrong in the spec.

Nick: The spec was pretty clear that you can't modify a readonly node, even through the DOM interface.

Erik: My impression is that this has lots of implications, and that the feature was not well thought out.

John: (highlighting sentence in spec about "the XForms Processor should not allow any changes to the bound instance data node")
... This is the only MIP that is not a property, it is a constraint.

<wellsk> (BTW charlie, eric and other scribes -- ya'll are doing great as I follow the discussions)

(Thanks Keith)

Nick: It is a property.

John: (Showing the new @calculate example to set a default value)
... @constraint is not enforced.

Nick: I know there are use cases for readonly in the UI, but I stand by my idea that @readonly must be enforced.

John: So you say that actions are impacted by this, unlike other properties.

Uli: Submission enforces @relevant.

Nick: If it's in the model, like submission, then it can be enforced by the model.

John: So insert and delete can't change anything underneath?

Nick: Yes, the spec says that.

John: One of the two statements in the spec is wrong.

Erik: I agree there is an inconsistency here.

Nick: The model should enforce.

John: I don't like this property being so powerful, but I could live with it, provided we clarify all over the places.

Erik: (question about instance replacement and delete/insert impact)

Nick: You can replace what's around a readonly node.

Erik: (doesn't understand why things would work this way)

Charlie: Seems like a bigger "change" to clarify this.

Nick: Several XForms implementations enforce this.

Uli: Chiba does enforce it too.

Erik: Does it support insert/delete?

Uli: No, only value change.

Erik: Other issue is the staleness of the MIP value

John: Approach 1) Readonly enforced by form controls
... 2) Readonly enforced by model and all actions and MIP staleness is not an issue

Charlie: (speaking about enforcing readonly for setvalue)

John: Question is whether setvalue has an effect or not.
... Let's focus first on the question of whether readonly needs to be enforced by setvalue and the other actions (through the model).

Nick: At my company we think that this enforcement is necessary.

John: I think that if the model enforces, we need to build that feature.

Nick: But it's already a feature.

John: Or build the other feature, which is readonly in the UI only.

Uli: Option 3) Only setvalue is impacted.

John: This is what our implementation was doing.

Nick: Some of our forms will definitely break.

Erik: For me, I don't see a very strong case for the super-strong encapsulation that Nick and Mark S. want.

Charlie: Many of us do option 2, but we are worried about the work that it will imply to clarify.

John: I don't think option 2 is right at all.
... I still think readonly is a property, consumed by the model at its leasure. It is consumed by the form controls and the submission.

Nick: We need the new UI-level readonly for what John wants.

John: No, I want the property to prevent the user to modify the data, and that's what I thought the spec did.

Erik: This is a fundamental discussion about XForms architecture: a black box-style of XForms model that enforces what the controller can do, vs. allowing actions to do pretty much everything.

<John_Boyer> must adjourn for now but all sides have been thoroughly discussed, so we need to make a choice tomorrow

- DRAFT -

Forms WG FtF, Madrid Spain, Day 2 of 3

13 Sep 2007

Attendees

Contents

XPath function issues

Issues with date-time functions

Issue 12

Issue 11

Issue 63

Issues 6 and 10

Issue 6

Demonstrations

Issue 8

Issue 13

Topic 9

Issue 38

Issue 29

Issue 50

Issue 176

Summary of Action Items

Scribe.perl diagnostic output