W3C Forms teleconference June 15, 2011

* Present

Alain Couthuries, AgenceXML
John Boyer, IBM
Leigh Klotz, Xerox
Nick van den Bleeken, Inventive Designers
Steven Pemberton, CWI/W3C (chair)
Philip Fennell, MarkLogic
Uli Lissé, DreamLabs
Erik Bruchez, Orbeon

* Agenda


* W3C Community Groups

Leigh Klotz: Can we leverage this for standardizing already developed technology? Can we leverage it? Is this a formalization of the thousands of invited experts for HTML?
Steven Pemberton: I think this was at the AC Meeting in Spain, but I'm surprised W3C didn't mention anything about it. There are Business Groups, which you pay for, and the other are Community Groups, which as far as I can see are free. Here's the W3C link: http://www.w3.org/QA/2011/04/coming_soon_w3c_community_grou.html
Steven Pemberton: "Four parties to agree...It's an open forum. No fees, no charters. Create support."
Leigh Klotz: What are "four parties"?
Steven Pemberton: Five individuals.
Leigh Klotz: We should start today. Since W3C is reducing investment in XML technologies.
Steven Pemberton: I don't know if we can establish a group for an existing WG.
Nick van: Would people do work there?
Leigh Klotz: Is this group worth the cost to its members, and is it work the hassle to W3C instead?
John Boyer: HTML5 is short-term. We are complementary and future-oriented, though giving value now. In a much-longer time frame we can upgrade. Upgrading the web is an enormous task. They continue to charter us.
Leigh Klotz: I'd like to find out of they're going to make community groups or not.
Steven Pemberton: It is happening. I'm surprised there's not an announcement on the news site.
Nick van: We might consider doing this for components or something experimental.
Steven Pemberton: Community Groups are mean to replace new incubator groups, and then form a WG to create the specification itself.

* Editorial Meeting

Steven Pemberton: Nick and I are meeting for two days next week.

* adjust-dateTime-to-timezone

http://lists.w3.org/Archives/Public/public-forms/2011May/0029.html http://lists.w3.org/Archives/Public/public-forms/2011Jun/0015.html http://lists.w3.org/Archives/Public/public-forms/2011Jun/0014.html

Leigh Klotz: Can we come to closure on this?
John Boyer: I have a couple of comments. The JavaScript Date object already does what I described, so it's implementable within a browser context. If I create a JavaScript date without a timezone, it attaches the timezone at that specified date. The XPath 2.0 dateTime constructor perhaps didn't have enough thought given to that edge case. It's easy in JavaScript, and important, to attach the right timezone given the browser's locale. For our server-side implementation, we determine that as well with Java ICU, and it understands entering and exiting daylight savings time. We already get the timezone from the client.
Steven Pemberton: So briefly, our conclusion is that we don't have to change the specification, and it's a clarification.
John Boyer: Perhaps just adding a few more examples. A date+61 days, giving a different timezone in the output, for example.
Steven Pemberton: That's time for a short time in the future, but what about 10 years?
John Boyer: Absolutely. If someone changes the rules it's a huge software update problem anyway.
Leigh Klotz: Perhaps there should be an NTP-like protocol for fetching DST rules for different locales.
John Boyer: Java already issues updates as does JavaScript.
Leigh Klotz: Yes, but nobody wants to recompile their refrigerator.
Nick van: I'll ask Michael Kay about XPath 2.0 doing this.
John Boyer: I will look at adjust-dateTime-to-timezone as the same kind of DOM-vs-XDM issue, so it's a piece of code that has to be written to smooth over the difference to provide the functionality.
Steven Pemberton: I think XForms should be the framework and the functions should be defined elsewhere as they're more far-reaching. That's my perfect position.
John Boyer: It still pays to ask the question about buggy functions.

ACTION-1804 Nick van den Bleeken to test XPath 2.0 dateTime constructor and ask Michael Kay.

ACTION-1805 John Boyer to create dateTime timezone examples.



John Boyer: The friendly-naming we're doing is commensurate with Apache JXPath and Google Maps service. If you compare the formats, the friendly-naming concept is being used.
Steven Pemberton: Something similar.
John Boyer: It's not JSON-to-XML translation, but when they produce both it looks like they use similar rules.
Steven Pemberton: Can you give us details, for example about anonymous arrays?
John Boyer: It's commensurate, not identical. Google Maps takes a profile of JSON. They don't care about round-trips. A zero-element JSON array produces no elements. There's no array-start; you just have more than one with the same name. So an array with one element and a singleton are the same. That's not designed for round-trip, so we'd have more features. Some work from IBM led to JSONX RFC in IETF, and it produces element names being the type, and the name of the element is an attribute. It's round-trippable but the XML is not friendly. I've updated the wiki page with complete examples.
John Boyer: I fixed the quote marks. I also changed personal names used.
John Boyer: Also, I changed the root element name from JSON to the root element.
Steven Pemberton: We chose JSON just so it would recognize it as a translation from JSON.
John Boyer: Is that necessary? Once it's in XML we can do anything we want. We might make it non-JSON. It's just data.
Steven Pemberton: On the one hand it doesn't matter.
John Boyer: It does matter when you convert it not for XForms. So it's either /root, /data, or /json.
Leigh Klotz: I have a slight preference for data, but I'm not going to object to root.
Steven Pemberton: I have a slight preference for json.
John Boyer: I find it easier to talk about the translation in text when I called it root. The team I'm working with has a big preference for root.
Steven Pemberton: If we add the mediatype to root then I have less concern.
John Boyer: The mapper would be configurable in a couple of ways; treating arrays as JXPath or element depth, for example. Having a mediatype attribute with application/json and MIME parameters for those configuration aspects. Is that a problem?
Steven Pemberton: No, not at all.
Leigh Klotz: It's about the XML, not about the JSON. So maybe separate attributes.
John Boyer: We need to have it on some other location in order to know to serialize it as JSON.
Leigh Klotz: Put it on application/xml+origin=json+options, not application/json+options.
John Boyer: Somehow you need it.
Steven Pemberton: Yes, don't lose information.
John Boyer: Yes, that makes sense, to show that the origin is JSON.
Leigh Klotz: I originally proposed associating it with the instance. For example, if you retrieve application/atom+xml we have no way to know that when you submit back, so it's not a JSON-specific problem.
John Boyer: Yes.
Nick van: You're doing something like namespaces.
Leigh Klotz: Namespaces on every element makes XPath painful. XSLT can recognize L34T with a single xsl:version attribute.
John Boyer: We could make it configurable what the root element is.
Steven Pemberton: I think it's OK, especially since people are doing other datatypes, such as vCard. They could use the same root element and then the mediaType to identify what it was translated from.
John Boyer: So a fromMediaType attribute for application/json.
Steven Pemberton: I don't think the name is too terribly important. fromMediaType doesn't give you more information than mediaType.
John Boyer: Leigh said he'd rather it be mediatype.
Leigh Klotz: My point was more that MIME parameters about the representation should go on the application/xml mediatype and not application/json.
John Boyer: I can write up these issues.
Steven Pemberton: One is strings in the value part vs. strings in names.
John Boyer: I misread "content of a string."
Steven Pemberton: It wasn't clear enough...it meant string as value, not string as name. The name is in the point above.
John Boyer: We have to do something about 0x00-0x1F.
Steven Pemberton: Last week we had the suggestion to change it just to backslash.
Nick van: Then you have to be careful about people typing backslash.
Steven Pemberton: Anything urgent?
John Boyer: Use of element depth for arrays.
Steven Pemberton: You've added an extra element?
John Boyer: Yes, I re-did all the examples. I showed hexencoding instead of underscores. For an element with no name I used double underscore and can't be produced by this encoding.
Steven Pemberton: How about $$?
John Boyer: I proposed replacing each illegal character with __hex__.
Steven Pemberton: Why?
John Boyer: Alain asked for it and then we don't need the name attribute.
Steven Pemberton: I don't like this because of the strange uses of underscore and it's not obvious how to convert.
John Boyer: They just have to look at the XML.
Steven Pemberton: How do you look at it?
John Boyer: You save it.
Steven Pemberton: It looks ugly and hard to write for. I'm not sure I'd want to go through it. If it says "*size" I know how to wite it for.
John Boyer: But then "*size" and "$size" produce the same element name.
Steven Pemberton: Then you use the @name attribute.
John Boyer: Then the author has to know if they're using name attributes.
Nick van: In your case the author has to know as well. If it's not representable in XML you have to do something else. There will be cases where you write something that doesn't work. Both have the same issue.
Steven Pemberton: The name attribute one allows you to use the JSON version.
John Boyer: If the JSON name has illegal characters, well that's an extreme edge case. It also gives us a way to represent the empty name.
Steven Pemberton: We hadn't thought about that one.
Leigh Klotz: How about a magic XPath function that escapes to __ or @name?
Steven Pemberton: It's nice because we don't need to change XForms.
Leigh Klotz: We could leave it to another spec to define the function.
Nick van: I like the function maybe. In John's case you can use a function to select a step with a string value.
John Boyer: You can only start an expression with a function.
Nick van: In XPath 2.0 you can have a function in the middle of a location path.
Leigh Klotz: It'd be better to have a clear, elegant, and simple encoding that's easy for all use cases but I'm not sure that's possible. A function would let you gloss over the harder cases, no matter how you encode it.
John Boyer: How about the nested element for arrays? It gives you the empty array, and it's consistent with nested arrays as well.
Steven Pemberton: I'll comment tomorrow.

* IRC Minutes


* Meeting Ends