<trackbot> Date: 29 May 2013

<scribe> scribe: nvdbleek

ACTION-1949 - Add note about use of var with other scripting

<Steven> languages

<Steven> http://lists.w3.org/Archives/Public/public-forms/2013May/0020.html

Steven: Looks alright for me

nvdbleek: Looks fine for me too

Steven: alain did you have a chance to look at it?

alain: It's ok for me

Steven: Erik thank you very much

<Steven> close action-1949

<trackbot> Closed ACTION-1949 Add note about use of var with other scripting languages..

ACTION-1947 - Import the XPath 3.0 serialize() function to XForms 2.0

http://lists.w3.org/Archives/Public/public-forms/2013May/0021.html

ACTION-1947 - Import the XPath 3.0 serialize() function to XForms

<Steven> 2.0

<Steven> http://lists.w3.org/Archives/Public/public-forms/2013May/0021.html

ebruchez: For this one I had a few more questions
... The way things are structured, Xpath 3.0 defines the function, the serialisation and the parameters are defined in XSLT and XQuery Serialization 3.0
... The serialisation spec allows you to extend the basic functionality, by default you can specify the method and some other parameters
... I think the parameters aren't mandatory to implement
... you can specify your own in your own namespace
... I added a JSON serialisation, relevant pruning and validation
... they are all in our namespace
... nvdbleek already commented on some of my questions
... historically yes and no are used, but we use true and false, what should we use, maybe support both
... The next question is what about failure, e.g. json serialisation may fail if you are serialising arbitrary XML

Steven: Certain things get ignored, I don't remember if JSON serialisation can fail

alain: If it doesn't fail, you could miss data

<ebruchez> http://www.w3.org/MarkUp/Forms/wiki/index.php?title=XPath_Expressions_Module&diff=3800&oldid=3750#The_serialize.28.29_Function

ebruchez: there is another error case, when you enable validate and the serialised item isn't valid
... On error we could return either an empty string or we could throw a dynamic error
... I think we should throw an error

alain: There is already an event

ebruchez: I don't like function sending events, because then you need to be able to send an event in the middle of evaluating an XPath expression, which could be handled. It works for submission because it is triggered in an action

alain: How can you catch a dynamic error in XPath?

ebruchez: XQuery has a try/catch mechanism but XPath doesn't has it

<ebruchez> http://www.w3.org/TR/xquery-30/#id-try-catch

nvdbleek: There are already other XPath functions that throw dynamic exception, we might add exception handling in a future version of the spec

ebruchez: When you do text serialisation you won't know the difference between serialising an empty element or an exception
... I think throwing an error is the right way to go

nvdbleek: +1 for throwing a dynamic error

alain: I would like to have media type as a serialisation parameter, are they all boolean
... why not use media type to configure the serialisation method

ebruchez: Because we decided to go for the xpath 3.0 serialise function. They have a serialisation method text, html, xml

alain: They are not media types

ebruchez: They are indeed not media types, they are just values

<ebruchez> http://www.w3.org/TR/xslt-xquery-serialization-30/#serparam

method: An expanded QName with a null namespace URI, and the local part of the name equal to one of xml, xhtml, html or text, or having a non-null namespace URI. If the namespace URI is non-null, the parameter specifies an implementation-defined output method.

Steven: It does a mediatype

… parameter as well

media-type: A string of Unicode characters specifying the media type (MIME content type) [RFC2046]; the charset parameter of the media type MUST NOT be specified explicitly in the value of the media-type parameter. If the destination of the serialized output is annotated with a media type, this parameter MAY be used to provide such an annotation. For example, it MAY be used to set the media type in an HTTP header.

ebruchez: In our case we couldn't use media-type because it doesn't influence the method parameter
... the supported parameters depend on the method parameter
... The spec doesn't say implement everything in the document, there are a lot of may's in the spec
... It is very flexible

Steven: alain doesn't like that this isn't fully in sync with the xforms submission because xforms uses media-type to drive the serialisation method

nvdbleek: I think we should go for extending the value space of method by adding xforms:json and xfroms:csv

ebruchez: I also think we should go for the xpath 3.0 function, I don't like the xpath 3.0 way of specifying the serialisation parameters, but we don't have to do all the specification work

Steven: Are you OK with it

alain: If we add CSV I'm OK with it

ebruchez: Most standard boolean serialization parameters are "yes" and "no".

Should we use that too, or "true" and "false"? Or accept both?

ebruchez: that is for xforms:relevance and xforms:validate

alain: I would like to go with yes and no

ebruchez: That's fine for me
... Is it unexpected to users that, by default, non-relevant nodes are pruned? This is consistent with xforms:submission

nvdbleek: I think we should go for pruning by default

<Steven> agree

ebruchez: I'm not sure about the xforms:validate parameter
... We have a valid() function, if you want to ensure that serialisation only happens when data is valid, you can use the valid() function
... If we keep the xforms:validate parameter we have to specify what should happen when validation is on and you have invalid nodes

<ebruchez> if (valid(foo)) then serialize(foo) else ''

ebruchez: you don't want to run the validation process while evaluating XPath expressions, consequently the data shouldn't be re-validated while running the serialize function

nvdbleek: I'm in favor of dropping the xforms:validate parameter

alain: +1 for removing xforms:validate parameter

ebruchez: How do we link to other specifications

<Steven> +1

nvdbleek: We add those to the references and and link to the reference from within the spec, We also point to dated versions of other specifications

ebruchez: nvdbleek comment "Shouldn't the default value for xforms:relevant be true (currently specified value is false)"
... We agreed to prune by default
... Let me double check the submission spec to make sure if it is specified correctly
... OK, you are correct, the default value should be true
... Others comments are no longer relevant because we dropped the xforms:validate parameter
... I can update the text accordingly

ACTION-1943: Erik investigate why XPath 3 chose the function

signature they did for serialization

http://lists.w3.org/Archives/Public/public-forms/2013May/0003.html

ebruchez: We covered this

<Steven> close action-1943

<trackbot> Closed ACTION-1943 Investigate why XPath 3 chose the function signature they did for serialization.

<Steven> Oh, hi Uli!

This is scribe.perl Revision: 1.138  of Date: 2013-04-25 13:59:11  
Check for newer version at http://dev.w3.org/cvsweb/~checkout~/2002/scribe/

Guessing input format: RRSAgent_Text_Format (score 1.00)

Succeeded: s/havoc/favor/
Found Scribe: nvdbleek
Inferring ScribeNick: nvdbleek
Default Present: Steven, [IPcaller], alain, ebruchez, nvdbleek, unl
Present: Steven [IPcaller] alain ebruchez nvdbleek unl
Regrets: Philip
Agenda: http://lists.w3.org/Archives/Public/public-forms/2013May/0023
Found Date: 29 May 2013
Guessing minutes URL: http://www.w3.org/2013/05/29-forms-minutes.html
People with action items: 

WARNING: Input appears to use implicit continuation lines.
You may need the "-implicitContinuations" option.