RE: Added support for utcTime in TTFMS (ACTION-741)

Hi Daniel,

Section 2.1 "Canonical EXI Options" mentions the default value for the
omitOptionsDocument option. When omitOptionsDocument is not present in
the Canonical EXI options document, we need to consider omitOptionsDocument
value to be false. I think this is the intention of the default value here.

In other words, section 2.1 does not specify the default value when
Canonical EXI options document is not exchanged. (i.e. exchanged out-of-band)

I am not sure if we need to test out-of-band scenarios since what
processors are expected to do in those situations are not described in
the specification.

[1] https://www.w3.org/TR/2016/CR-exi-c14n-20161103/#canonicalOptions

Thank you,

Takuki Kamiya
Fujitsu Laboratories of America


From: Peintner, Daniel [mailto:daniel.peintner.ext@siemens.com]
Sent: Monday, November 28, 2016 7:33 AM
To: Takuki Kamiya <tkamiya@us.fujitsu.com>; public-exi@w3.org
Subject: AW: Added support for utcTime in TTFMS (ACTION-741)


Hi Taki,

Thank you for your work.

> For omitOptionsDocument parameter, I think we can use an existing parameter
> "org.w3c.exi.ttf.includeOptions" instead. We can consider omitOptionsDocument
> to be the logical negation of includeOptions.

After running first tests I am not sure whether this assumption is the case. Let me explain my concern.

We identify "Canonical EXI" test-runs by looking at

if("iot_c14n_encode".equals(driverParams.measure.toString())) {
/*Canonical EXI*
}

Correct?

Also
* the boolean parameter "includeOptions" is always set
  and by default false
* by default "omitOptionsDocument" is false also.

The issue, I think, is that the default behavior for EXI and Canonical EXI is the opposite.
The order to deal with "Canonical EXI" parameters is of importance. We need to agree that a driver needs to first check "iot_c14n_encode" which would by default set  "omitOptionsDocument" to false (or "includeOptions" to true). Then we need to check the actual "includeOptions"parameter and overwrite the previous assumption...

Do you see my concern?

Thanks,

-- Daniel