SISR Recommendation: _attributes and _nsprefix in arrays

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