[xquery-talk] Adaptive serialization and indendation

[Joe Wicentowski]

Hi all,

I'm involved in commissioning the addition of adaptive serialization [1] to
eXist [2], and I would like to confirm my reading of the spec. It appears
that adaptive serialization has no facility for indenting maps and arrays.
The ser/method-adaptive.xml tests in the qt3 test suite reflect this
understanding, esp. tests 32-34.

In other words, `map { "a": "b", "c": "d" }` must be serialized as
`map{"a":"b","c":"d"}` without any whitespace inserted inside the map
constructor or between the map entries, and it would be *incorrect* to
serialize this map as:

```
map {
"a": "b",
"c": "d"
}
```

Is there room for implementations to use such indentation and still call it
"adaptive"? If so, what basis is there in the spec for such behavior?

Thanks in advance for any insights into this question,
Joe

[1] https://www.w3.org/TR/xslt-xquery-serialization-31/#adaptive-output
[2] https://github.com/eXist-db/exist/issues/1124

[Liam R. E. Quin]

Post by Joe Wicentowski
[...]
Is there room for implementations to use such indentation and still
call it "adaptive"?  If so, what basis is there in the spec for such
behavior?

Here's a personal response - use bugzilla (see the status section of
the spec,
https://www.w3.org/TR/xslt-xquery-serialization-31/
for details) if you want a Working Group response.

The Working Group will probably close soon, however.

So,

https://www.w3.org/TR/xslt-xquery-serialization-31/#JSON_INDENT
has, for JSON,
[[
The indent parameter controls whether the serializer adjusts the
whitespace in the serialized result so that a person will find it
easier to read.
]]
(the spec doesn't say _which_ person!).

OK, and now we see, in 10.1,
[[
For some item types the Adaptive output method will delegate
serialization to other output methods. [...] serialization parameters, 
if set, will be passed down to the serialization method that is
applied  to each item in the supplied sequence.
]]

So as I read it you have as implementor a license to pass the indent
parameter down and to use JSON serialization for maps and arrays and
hence to allow the readable indenting.

Certainly that's in the _spirit_ of the adaptive method. And using a
serialization parameter would also let you pass the tests :) although
I don't know how important that is to you.

Again, this is based on my own reading of the spec, and being at the
meetings and on the calls, but it's not an "official" response.

Best,

Liam

[Joe Wicentowski]

Hi Liam,

Many thanks for this helpful response about the "spirit" of the spec here.
I have one last question - do you have a sense why section 10.1.4 makes
this statement?

The indent and suppress-indentation parameters are not directly

applicable to the Adaptive output method. [1]

(What throws me off a bit here, of course, is that Adaptive is the only
output method that serializes maps *as* maps, so there isn't anywhere else
to look for direct guidance on indentation of maps.)

I may well proceed with the bugzilla request, but if you have any further
insight on this question, it would help me understand whether the current
phrasing was an unintentional oversight or whether there was some other
consideration that led the WG to state the above.

Thanks again,
Joe

[1] https://www.w3.org/TR/xslt-xquery-serialization-31/#ADAPTIVE_INDENT

Post by Joe Wicentowski
[...]
Is there room for implementations to use such indentation and still
call it "adaptive"? If so, what basis is there in the spec for such
behavior?

Here's a personal response - use bugzilla (see the status section of
the spec,
https://www.w3.org/TR/xslt-xquery-serialization-31/
for details) if you want a Working Group response.
The Working Group will probably close soon, however.
So,
https://www.w3.org/TR/xslt-xquery-serialization-31/#JSON_INDENT
has, for JSON,
[[
The indent parameter controls whether the serializer adjusts the
whitespace in the serialized result so that a person will find it
easier to read.
]]
(the spec doesn't say _which_ person!).
OK, and now we see, in 10.1,
[[
For some item types the Adaptive output method will delegate
serialization to other output methods. [...] serialization parameters,
if set, will be passed down to the serialization method that is
applied to each item in the supplied sequence.
]]
So as I read it you have as implementor a license to pass the indent
parameter down and to use JSON serialization for maps and arrays and
hence to allow the readable indenting.
Certainly that's in the _spirit_ of the adaptive method. And using a
serialization parameter would also let you pass the tests :) although
I don't know how important that is to you.
Again, this is based on my own reading of the spec, and being at the
meetings and on the calls, but it's not an "official" response.
Best,
Liam
--
The World Wide Web Consortium (W3C)

[Michael Kay]

I think the key to this is the word "directly". For many things the adaptive methods delegates to other output methods, and in cases where the adaptive method does not itself use a serialization parameter, but the method to which it delegates does, the phrase "is not directly applicable" is used. This is explained in section 10.1 of the serialization spec.

Michael Kay
Saxonica

Post by Joe Wicentowski
Hi Liam,
Many thanks for this helpful response about the "spirit" of the spec here. I have one last question - do you have a sense why section 10.1.4 makes this statement?

The indent and suppress-indentation parameters are not directly applicable to the Adaptive output method. [1]

(What throws me off a bit here, of course, is that Adaptive is the only output method that serializes maps *as* maps, so there isn't anywhere else to look for direct guidance on indentation of maps.)
I may well proceed with the bugzilla request, but if you have any further insight on this question, it would help me understand whether the current phrasing was an unintentional oversight or whether there was some other consideration that led the WG to state the above.
Thanks again,
Joe
[1] https://www.w3.org/TR/xslt-xquery-serialization-31/#ADAPTIVE_INDENT <https://www.w3.org/TR/xslt-xquery-serialization-31/#ADAPTIVE_INDENT>

[...]
Is there room for implementations to use such indentation and still
call it "adaptive"? If so, what basis is there in the spec for such
behavior?

Here's a personal response - use bugzilla (see the status section of
the spec,
https://www.w3.org/TR/xslt-xquery-serialization-31/ <https://www.w3.org/TR/xslt-xquery-serialization-31/>
for details) if you want a Working Group response.
The Working Group will probably close soon, however.
So,
https://www.w3.org/TR/xslt-xquery-serialization-31/#JSON_INDENT <https://www.w3.org/TR/xslt-xquery-serialization-31/#JSON_INDENT>
has, for JSON,
[[
The indent parameter controls whether the serializer adjusts the
whitespace in the serialized result so that a person will find it
easier to read.
]]
(the spec doesn't say _which_ person!).
OK, and now we see, in 10.1,
[[
For some item types the Adaptive output method will delegate
serialization to other output methods. [...] serialization parameters,
if set, will be passed down to the serialization method that is
applied to each item in the supplied sequence.
]]
So as I read it you have as implementor a license to pass the indent
parameter down and to use JSON serialization for maps and arrays and
hence to allow the readable indenting.
Certainly that's in the _spirit_ of the adaptive method. And using a
serialization parameter would also let you pass the tests :) although
I don't know how important that is to you.
Again, this is based on my own reading of the spec, and being at the
meetings and on the calls, but it's not an "official" response.
Best,
Liam
--
The World Wide Web Consortium (W3C)
_______________________________________________
http://x-query.com/mailman/listinfo/talk

[Joe Wicentowski]

Hi Michael,

Thanks for your reply. Would it be accurate to say, then, that the indent
parameter is delegated to the JSON output method when serializing map and
array items under the Adaptive output method?

I ask because I don't see anything explicitly stating that the JSON output
method is the delegate for serialization parameters affecting map and array
items under Adaptive output method. But since no other output method
claims to be able to serialize map and array items, the spec makes this
conclusion implicitly.

Joe

Post by Michael Kay
I think the key to this is the word "directly". For many things the
adaptive methods delegates to other output methods, and in cases where the
adaptive method does not itself use a serialization parameter, but the
method to which it delegates does, the phrase "is not directly applicable"
is used. This is explained in section 10.1 of the serialization spec.
Michael Kay
Saxonica
Hi Liam,
Many thanks for this helpful response about the "spirit" of the spec
here. I have one last question - do you have a sense why section 10.1.4
makes this statement?

The indent and suppress-indentation parameters are not directly

applicable to the Adaptive output method. [1]
(What throws me off a bit here, of course, is that Adaptive is the only
output method that serializes maps *as* maps, so there isn't anywhere else
to look for direct guidance on indentation of maps.)
I may well proceed with the bugzilla request, but if you have any further
insight on this question, it would help me understand whether the current
phrasing was an unintentional oversight or whether there was some other
consideration that led the WG to state the above.
Thanks again,
Joe
[1] https://www.w3.org/TR/xslt-xquery-serialization-31/#ADAPTIVE_INDENT

Post by Joe Wicentowski
[...]
Is there room for implementations to use such indentation and still
call it "adaptive"? If so, what basis is there in the spec for such
behavior?

Here's a personal response - use bugzilla (see the status section of
the spec,
https://www.w3.org/TR/xslt-xquery-serialization-31/
for details) if you want a Working Group response.
The Working Group will probably close soon, however.
So,
https://www.w3.org/TR/xslt-xquery-serialization-31/#JSON_INDENT
has, for JSON,
[[
The indent parameter controls whether the serializer adjusts the
whitespace in the serialized result so that a person will find it
easier to read.
]]
(the spec doesn't say _which_ person!).
OK, and now we see, in 10.1,
[[
For some item types the Adaptive output method will delegate
serialization to other output methods. [...] serialization parameters,
if set, will be passed down to the serialization method that is
applied to each item in the supplied sequence.
]]
So as I read it you have as implementor a license to pass the indent
parameter down and to use JSON serialization for maps and arrays and
hence to allow the readable indenting.
Certainly that's in the _spirit_ of the adaptive method. And using a
serialization parameter would also let you pass the tests :) although
I don't know how important that is to you.
Again, this is based on my own reading of the spec, and being at the
meetings and on the calls, but it's not an "official" response.
Best,
Liam
--
The World Wide Web Consortium (W3C)

_______________________________________________
http://x-query.com/mailman/listinfo/talk

[Liam R. E. Quin]

Post by Joe Wicentowski
Hi Liam,
Many thanks for this helpful response about the "spirit" of the spec here.
I have one last question - do you have a sense why section 10.1.4 makes
this statement?

The indent and suppress-indentation parameters are not directly

applicable to the Adaptive output method. [1]

it's saying that if the implementation delegates to another
serialization method for part or all of the output, the indent and
suppress-indentation parameters are to be passed on to that method.

Post by Joe Wicentowski
(What throws me off a bit here, of course, is that Adaptive is the only
output method that serializes maps *as* maps, so there isn't anywhere else
to look for direct guidance on indentation of maps.)

In principle doesn't JSON do that too? Which is why I think delegating
map serialization to the JSON method might make sense.

If you do plan to file an issue against the spec, do it soon - I think
the XQuery Working Group might only have two or three more meetings
before it closes. XSLT will be going perhaps a little longer but is
focused on XSLT 3.

Liam