See also: IRC log
<trackbot> Date: 29 May 2013
<scribe> scribe: nvdbleek
<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..
http://lists.w3.org/Archives/Public/public-forms/2013May/0021.html
<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: 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
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.[End of scribe.perl diagnostic output]