Forms Working Group Teleconference -- 17 Apr 2013

<trackbot> Date: 17 April 2013

Next week

Steven: I'm sending regrets, for the W3C Open Data workshop

Nick: I'm at a FtF in the US

Steven: Shall we cancel next week then?

[agreement]

Concerns about format token parameter on serialize() and parse()

functions

http://lists.w3.org/Archives/Public/public-forms/2013Apr/0017.html

http://lists.w3.org/Archives/Public/public-forms/2012Nov/0012.html

Erik: [describes the problem, as in the mail]
... Saxon serialisation can take XSL <output>
... XPath 3 is similar, but with nested elements in <output>; rather ugly, but the same dea of using indirection.
... if e just need name/value pairs, then it doesn't really matter what we use.

s/ e // we /

scribe: one thing to be aware of, when passing to a function, an element or an attribute, we can only pass something in instance data
... we can't pass a submission element except by ID.
... ... You might have to create a special instane
... that's method 1.

Erik: Method 2, is closer to Steven's proposal, using any element in theory.
... the problem with a submission element is that the spec requires certain fields
... which is a problem because we don't need them in this case.
... or we change the defn of the submission element
... which makes it then useless for <send>
... which makes run-time changes, to deal with when they are missing
... so we could say that we use any element, which might be a <submission/>, but also other elements, inside or outside an instance

Nick: XForms expressions can't reference nodes outside an instance

Erik: It can if you use an ID

<ebruchez> "The schema list may include URI fragments referring to elements located outside the current model elsewhere in the containing document; e.g. "#myschema". xs:schema elements located inside the current model need not be listed."

Nick: This would be the first time that an XPath expression needs access to stuff outside the instance

Erik: See above quote
... there are earlier examples
... Imagine a browser-side implementation, you don't need to use XPath in the implementation

Nick: But the ID resolution scope is different

Erik: We already have that, <toggle .../> for instance
... The id function isn't being use, it is a string
... are there really no other examples of XPath functions using an ID? Our implementation has several
... with that method you could write this:

<ebruchez> serialize(., id('foo'))

<ebruchez> serialize(., 'foo')

Erik: I'm not a super fan of this type of overloading

Nick: Confusing for users, since sometimes we do an extra resolution.

Erik: Not sure I understand.

Nick: [breaks up]

<nvdbleek> http://www.w3.org/TR/xforms-xpath/#The_id.28.29_Function

Nick: The first arg can be a seq of nodes

Erik: But that's deprecated; we say to use ID

<nvdbleek> This may be in the form of a string containing a space-separated list of IDREFs or a sequence of nodes, each node of which contains an IDREF.

Erik: That is an example of a function that can take a string or an element. Is it wise? Do we want one way or multiple ways?
... Sometimes you want to change the values; but conversely it is annoying to have to create an instance for static values.
... but on the other hand it's not that much extra convenience

<ebruchez> Here is the xf:case() function: http://www.w3.org/TR/xforms-xpath/#fn-case which takes a switch id

Steven: I'm veering towards the instance solution

Erik: We only need the attributes in that case.
... this would make the second parameter being an XPath expression for an element

<ebruchez> 2. serialize($arg as item()*, $params as element()) (: point to

<ebruchez> element and use its attributes :)

<ebruchez> 2. serialize($arg as item()*, $params as element()) (: point to element and use its attributes :)

Erik: That would be the simplest as far as function signature is concerned

<ebruchez> fn:serialize($arg as item()*, $params as element(output:serialization-parameters)?) as xs:string

<ebruchez> that's XPath 3's

Erik: That is the XPath 3 signature, which is very similar
... I think this supports something that is more complicated/richer

<ebruchez> http://www.w3.org/TR/xslt-xquery-serialization-30/#serparams-in-xdm-instance

Erik: They use elements, not attributes.
... which is really heavy
... I don't know why they did this

<scribe> ACTION: Erik investigate why XPath 3 chose the function signature they did for serialization [recorded in http://www.w3.org/2013/04/17-forms-minutes.html#action01]

<trackbot> Created ACTION-1943 - Investigate why XPath 3 chose the function signature they did for serialization [on Erik Bruchez - due 2013-04-24].

ACTION-1943, due 2013-05-01

action-1943?

<trackbot> ACTION-1943 -- Erik Bruchez to investigate why XPath 3 chose the function signature they did for serialization -- due 2013-04-24 -- OPEN

<trackbot> https://www.w3.org/2005/06/tracker/xforms/actions/1943

Erik: So this seems like a good solution; is there anything we need to look at in XPath 3? Is it overkill? I will look.

<nvdbleek> action-83 due 1 May 2013

<trackbot> Set ACTION-83 MarkB and Raman to resurrect custom control document in time for Technical Plenary (replace previous action item) due date to 1 May 2013.

action-1943, due 2013-05-01

<nvdbleek> action-1943, due 1 May 2013

<nvdbleek> action-1943 due 1 May 2013

<trackbot> Set ACTION-1943 Investigate why XPath 3 chose the function signature they did for serialization due date to 1 May 2013.

action-1943 due 2013-05-01

<trackbot> Set ACTION-1943 Investigate why XPath 3 chose the function signature they did for serialization due date to 2013-05-01.

Steven: So we keep this on the agenda until Erik has completed his XPath 3 investigations