xml-dev - Re: Array content model

[Ken MacLeod <ken@bitsko.slc.ut.us>]

John.OSullivan@chase.com writes:

> I am part of the FpML (www.fpml.org) Architecture Working Group
> tasked with developing a new basic content model for FpML. My
> group has been debating how to express arrays or lists in FpML.
> In the first example of a list or array in the Schema primer
> (http://www.w3.org/TR/xmlschema-0/) we have a list of two
> instances of item, bracketed by in items tags...

[abbreviated]
> <purchaseOrder orderDate="1999-10-20">
>     <items>
>         <item partNum="926-AA">
>             <!-- detail elided -->
>         </item>
>     </items>
> </purchaseOrder>
> 
> Opinion in our working group is in favour of dropping the items tags
> in our content model, and embedding the instances of item directly
> in the parent element, purchaseOrder, yielding...
> 
> <purchaseOrder orderDate="1999-10-20">
>     <item partNum="872-AA">
>         <!-- detail elided -->
>     </item>
>     <item partNum="926-AA">
>         <!-- detail elided -->
>     </item>
> </purchaseOrder>
> 
> I favour the former arrangement, with the instances of item
> contained within an items element. I prefer it since it is easier to
> implement [...]

> However, my colleagues are unmoved by the ease of implementation
> argument, and prefer the gain in brevity from omiting the items
> tags.

If you're going to write your own serializer, then they are probably
right.  A simple optimization for ease of implementation over ease of
readability (read: debuggability) is probably not a big deal, in the
end.

> I'd be very grateful for any comment and argument for or against
> either of these positions from xml-devers.

OTOH, if you're willing to live by a few imposed rules, you can use
somebody else's serializer and probably gain in the long run by
improvements in the serializer that somebody else is working on
continuously.  SOAP, as one example, favors your former format over
the latter, as well as favoring element content for data over element
attributes for data.

For a recent project, we already used only element content so
switching to SOAP's serialization (not RPC) required only a few
attribute changes and now we use the SOAP de/serializer I wrote at
<http://Casbah.org/Scarab/>.

> Especially with regard to the implications of schemas.

Schemas, I believe, are flexible enough for any format you choose.
The "imposed rules" I speak of above typically restrict the
flexibility available to you in favor of generalizing the
serialization code.  SOAP, again as an example, has schema support as
one of its goals so that you can use the XML with or without a SOAP
implementation and still have schema validation available to you.

  -- Ken

***************************************************************************
This is xml-dev, the mailing list for XML developers.
To unsubscribe, mailto:majordomo@xml.org&BODY=unsubscribe%20xml-dev
List archives are available at http://xml.org/archives/xml-dev/
***************************************************************************