Replay on Minutes for OASIS SDD TC 01/07/2010 Meeting, 4.c

["Borissov, Lazar" <lazar.borissov@sap.com>]

Hello,
Here I would like to replay on following raised by Merri issue. I will also join tomorrow phone call for the first half hour:

From "Minutes for OASIS SDD TC 01/07/2010 Meeting"
4.c.      Specification updates: Merri raised one issue: when updating the specification for the previously approved proposal from SAP for additional parameter types, it was unclear how to explain the array parameter type, especially the boolean and URI arrays. In particular, Integer and String types include additional information (integer bounds, string length) and hence these are sub-elements of the array type. However, URI and boolean types do not include any additional information, and so having these as sub-elements rather than attributes adds complexity. Merri suggests that we revisit the schema for this item. Jason and Randy to review schema and recommend updates, if any; Brent will also ask Lazar to provide feedback on why the current method was chosen.

----
I agree having simple data types as subelements adds some complexity. On the other hand how you propose to define this as simple attribute - have attribute type with let's say value "boolean" or "URI". This will of course work but than we at least have modeling inconsistency - some types are defined as first subelement, others as simple attribute. Maybe we may change this by declaring the type as attribute which is either simple string for "boolean"/"URI" or reference to complex type for string/integer?!?

My reasoning for this schema was the consistency: any type is declared following the same, consistent pattern: first element is the type (even if simple type), next elements are array values

Best regards,

-----
Lazar Borissov

TD LM Software Logistics

Sap Labs Bulgaria Ltd.
Blvd. 'Tzar Boris 3', 136A
1618 Sofia, Bulgaria
T: +359/2 9157-284
Mobile: +359/887 887-450
F: +359/2 9157-691