[XML-DEV Mailing List Archive Home] [By Thread] [By Date] [Recent Entries] [Reply To This Message] Re: Array content model
John.OSullivan@c... 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@x...&BODY=unsubscribe%20xml-dev List archives are available at http://xml.org/archives/xml-dev/ ***************************************************************************
|
PURCHASE STYLUS STUDIO ONLINE TODAY!Purchasing Stylus Studio from our online shop is Easy, Secure and Value Priced! Download The World's Best XML IDE!Accelerate XML development with our award-winning XML IDE - Download a free trial today! Subscribe in XML format
|