OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.


Help: OASIS Mailing Lists Help | MarkMail Help

dita-sidsc message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]

Subject: [dita-sidsc] Finished updating register element spreadsheet.

I have finished updating the register element spreadsheet. I thought it would send out an email but neither Doug nor I has received one yet, so maybe I did something wrong.
If you later get the official email, I apologize for the duplication. Here is the message I tried to send:
The SIDSC dimension element is defined to be a string that supports a comma-separated list of integers. <dimension> can be instantiated multiple times.
The IP-XACT dim element on which the SIDSC element was based is defined as an integer. <dim> too can be instantiated multiple times.
I recommend we adopt the IP-XACT convention of using multiply instantiated integer values, then realign with the next revision of IP-XACT if we choose. We clearly don't need or want both a comma-separated list and multiple instantiation, and I think the comma-separated list will be troublesome both to parse and to validate. Using integer values also mirrors the current IP-XACT schemas.
It looks to me as though an IP-XACT annotation on the dim element was misinterpreted when the SIDSC element was being developed. This annotation reads "Dimensions a register array, the semantics for dim elements are the same as the C language standard for the layout of memory in multidimensional arrays."
A Freescale person who is involved with IP-XACT  confirmed that the intent of this annotation was to signal a document order dependence. In other words, dim elements are defined in the same order they would appear in a C language array declaration, and they should be interpreted as such. This is recognized among IP-XACT members as a potential source of trouble.
One possible solution would be to introduce a list structure in which the ordering of dimensions is made explicit. Another solution would be to nest dim elements, so that the logical structure of a multi-dimension array would be mirrored in the element structure. Both solutions are being considered for IP-XACT rev 1.5 due in early 2009.
However, my source said that to the best of his knowledge, no one has proposed changing the <dim> element into a non-integer.
with best regards
Tom Cihak
Freescale Semiconductor

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]