- From: Peintner, Daniel <daniel.peintner.ext@siemens.com>
- Date: Mon, 28 Nov 2016 15:32:43 +0000
- To: Takuki Kamiya <tkamiya@us.fujitsu.com>, "public-exi@w3.org" <public-exi@w3.org>
Received on Monday, 28 November 2016 15:33:35 UTC
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
Received on Monday, 28 November 2016 15:33:35 UTC