- From: Serge LE HUITOUZE <slehuitouze@telisma.com>
- Date: Thu, 8 Nov 2007 17:34:32 +0100
- To: <www-voice@w3.org>
Hello voice, Yet a few questions regarding dark corners of EMMA serialization... Sure, these are dark corners, but they deserve being made clear! At section 7.2, it is written: * Properties specified in the _attributes object are rendered as XML * attributes of the containing object This is pretty clear, as illustrated by the following SISR tag: * EXAMPLE 1 * out.x = {_attributes:{at1:27}} which unambiguously generates the following EMMA serialization: * <x at1="27"></x> But is this also true when the said parent object is an (automatically generated) item coming from an array? E.g., what about the following SISR tag?: * EXAMPLE 2 * out.x = [22,{_attributes:{at1:"27"}}] The way I interpret the spec, I expect: * <x length="2"><item index="0">22</item><item index="1" at1="27"></item></x> I.e., the (automatically generated) item integrates the extra attribute coming from the array's second element. Anyone to confirm? Now, what should happen if the attribute coming from an array element has the name "index"? E.g.: * EXAMPLE 3 * out.x = [22,{_attributes:{index:"27"}}] Is the result going to be?: * <x length="2"><item index="0">22</item><item index="27"></item></x> I would find this unwise, to say the least!... Similarly, conflicts will arise with the special attribute "_nsprefix" in an array element: This would lead to changing the corresponding "item" tag into a "someNS:item" tag which would not be compatible with its "item" brothers (or "otherNS:item" brothers if the array itself had the "_nsprefix" property)... E.g., the following SISR tag with two conflicting "_nsprefix" properties: * EXAMPLE 4 * out.p=["one",{_nsprefix:"n2",v:27}]; out.p._nsprefix="n1"; This may result in: * <p n1:length="2"> * <n1:item n1:index="0">one</n1:item> * <n2:item n1:index="1"><v>27</v></n2:item> * <p> Which, again, is pretty unwise... Weird things may also happen if a property of an "_attributes" sub-object has name "length": This would make the containing object look like an array, which it is not! Again, these examples are quite contrived (except, maybe, EXAMPLE 2). Nevertheless, the spec has to be crystal-clear about them. For all these examples, two solutions are possible: - consider them as errors (my preferred choice); - state rule(s) explaining when and how containing objects are affected by contained sub-objects with reserved properties. Comments anyone? Regards. --Serge Le Huitouze No virus found in this outgoing message. Checked by AVG Free Edition. Version: 7.5.503 / Virus Database: 269.15.24/1117 - Release Date: 07/11/2007 22:52
Received on Thursday, 8 November 2007 16:34:39 UTC