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
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 in June/July Amsterdam, July 20-21.
Steven Pemberton: Nick and I are meeting for two days next week.
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.