Hi all,
As I read the serialization spec ( https://www.w3.org/TR/xslt-xquery-serialization-31/#serparam), additional values for the "method" parameter and additional serialization parameters should use a non-null namespace URI (see quotes below).
I believe BaseX's "csv" method or "tabulator" parameter ( http://docs.basex.org/wiki/Serialization) would fall into this category. Without such a non-null namespace URI, users may mistake BaseX-specific serialization features for those supported in the spec. The solution that the spec seems to suggest would be to use "basex:csv" or "basex:tabulator". I bet such a change would be unwelcome to those with code that uses the existing supported values, but aside from a disruptive cycle of deprecating existing values, etc., an alternative would be for the BaseX documentation to note this non-compliance with the spec.
I realize this is nit-picky, but I thought it might be worth raising given the potential for confusion mentioned above, and should this discussion be of interest to anyone.
Best, Joe
Regarding values for the "method" parameter:
The value of the method parameter is an expanded QName. If the value has
a null namespace URI, then the local name identifies a method specified in this document and MUST be one of xml, html, xhtml, text, json , or adaptive; in this case, the output method specified MUST be used for serializing. If the namespace URI is non-null, then it identifies an implementation-defined output method; the behavior in this case is not specified by this document.
Regarding additional serialization parameters:
Implementations MAY define additional serialization parameters, and MAY
allow users to do so. For this purpose, the name of a serialization parameter is considered to be a QName; the parameters listed above are QNames whose expanded-QName has a null namespace URI, while any additional serialization parameters that are either implementation-defined or defined by the host language MUST have names that are namespace-qualified.
Hi Joe,
You are completely right; we ignored this specific rule of the specification in the past. One of the reasons is that there are many ways in BaseX how parameters can be supplied, and in some cases, no namespace prefixes can be declared. I have just updated our serialization [1]; I hope that the new wording is helpful.
As you indicated, a change would require various changes in existing XQuery libraries. I’ll have some more thoughts on this; maybe we could tackle this with version 10 of BaseX.
Thanks for your observation! Christian
[1] http://docs.basex.org/wiki/Serialization
As I read the serialization spec (https://www.w3.org/TR/xslt-xquery-serialization-31/#serparam), additional values for the "method" parameter and additional serialization parameters should use a non-null namespace URI (see quotes below).
I believe BaseX's "csv" method or "tabulator" parameter (http://docs.basex.org/wiki/Serialization) would fall into this category. Without such a non-null namespace URI, users may mistake BaseX-specific serialization features for those supported in the spec. The solution that the spec seems to suggest would be to use "basex:csv" or "basex:tabulator". I bet such a change would be unwelcome to those with code that uses the existing supported values, but aside from a disruptive cycle of deprecating existing values, etc., an alternative would be for the BaseX documentation to note this non-compliance with the spec.
I realize this is nit-picky, but I thought it might be worth raising given the potential for confusion mentioned above, and should this discussion be of interest to anyone.
Best, Joe
Regarding values for the "method" parameter:
The value of the method parameter is an expanded QName. If the value has a null namespace URI, then the local name identifies a method specified in this document and MUST be one of xml, html, xhtml, text, json , or adaptive; in this case, the output method specified MUST be used for serializing. If the namespace URI is non-null, then it identifies an implementation-defined output method; the behavior in this case is not specified by this document.
Regarding additional serialization parameters:
Implementations MAY define additional serialization parameters, and MAY allow users to do so. For this purpose, the name of a serialization parameter is considered to be a QName; the parameters listed above are QNames whose expanded-QName has a null namespace URI, while any additional serialization parameters that are either implementation-defined or defined by the host language MUST have names that are namespace-qualified.
Thank you, Christian! Your edit to the documentation completely clears this up.
Best, Joe
On Thu, Jan 17, 2019 at 4:22 AM Christian Grün christian.gruen@gmail.com wrote:
Hi Joe,
You are completely right; we ignored this specific rule of the specification in the past. One of the reasons is that there are many ways in BaseX how parameters can be supplied, and in some cases, no namespace prefixes can be declared. I have just updated our serialization [1]; I hope that the new wording is helpful.
As you indicated, a change would require various changes in existing XQuery libraries. I’ll have some more thoughts on this; maybe we could tackle this with version 10 of BaseX.
Thanks for your observation! Christian
[1] http://docs.basex.org/wiki/Serialization
As I read the serialization spec (
https://www.w3.org/TR/xslt-xquery-serialization-31/#serparam), additional values for the "method" parameter and additional serialization parameters should use a non-null namespace URI (see quotes below).
I believe BaseX's "csv" method or "tabulator" parameter (
http://docs.basex.org/wiki/Serialization) would fall into this category. Without such a non-null namespace URI, users may mistake BaseX-specific serialization features for those supported in the spec. The solution that the spec seems to suggest would be to use "basex:csv" or "basex:tabulator". I bet such a change would be unwelcome to those with code that uses the existing supported values, but aside from a disruptive cycle of deprecating existing values, etc., an alternative would be for the BaseX documentation to note this non-compliance with the spec.
I realize this is nit-picky, but I thought it might be worth raising
given the potential for confusion mentioned above, and should this discussion be of interest to anyone.
Best, Joe
Regarding values for the "method" parameter:
The value of the method parameter is an expanded QName. If the value
has a null namespace URI, then the local name identifies a method specified in this document and MUST be one of xml, html, xhtml, text, json , or adaptive; in this case, the output method specified MUST be used for serializing. If the namespace URI is non-null, then it identifies an implementation-defined output method; the behavior in this case is not specified by this document.
Regarding additional serialization parameters:
Implementations MAY define additional serialization parameters, and
MAY allow users to do so. For this purpose, the name of a serialization parameter is considered to be a QName; the parameters listed above are QNames whose expanded-QName has a null namespace URI, while any additional serialization parameters that are either implementation-defined or defined by the host language MUST have names that are namespace-qualified.
basex-talk@mailman.uni-konstanz.de
-
Christian Grün -
Joe Wicentowski