[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [xml-dev] Using Wrapper Elements in Schemas - Any Best Practices?
- From: firstname.lastname@example.org
- To: email@example.com
- Date: Mon, 24 Sep 2001 10:56:29 -0400
Actually, I'd suggest that placing the duration element on each
<symptom> would accomplish the same thing while allowing greater processing
flexibility. That being said, I'd still recommend the container element
approach (unless you're REALLLLY pressed for optimizations). The extra
element certainly doesn't hurt, and it allows you to process the group as a
list much more easily. Particularlay if you'll need to do any manual
creation of the structure (some editors can be more helpful if they can
As a pure matter of style, I'd also suggest not using the plural of
the element's names as the name of the container (<symptoms> in your
example). Then you have to say things like "symptoms contains symtpoms",
which isn't really what you mean. I'd go for something like <symptom_list>
Michael A. Rossi
Computer Sciences Corporation
<Brian.Magick@C To: firstname.lastname@example.org
Subject: [xml-dev] Using Wrapper Elements in Schemas - Any Best
09/24/01 10:37 Practices?
Are there any best practices for using wrapper elements in XML Schemas? We
are having an internal debate on the merits of using wrappers, I summarize
my opinions below.
The debate??should a set of symptoms be represented by a series of symptom
tags alone or should they be contained in a <symptoms> wrapper element.
<symptom> This is symptom 1 </symptom>
<symptom> This is symptom 2 </symptom>
<symptom> This is symptom 3 </symptom>
My initial thoughts: I think wrappers are useful when you need to group
some tags and possibly need a lead wrapper element to capture some
attributes or metadata. For example (yes this might be a bit silly)
perhaps we want to know the symptoms based on how long they have been
persisting. Maybe some symptoms have been around for 7 days and other for
just 3. The following XML, using wrapper elements, accomplishes the
description of this quite well.
Of course, this is just my opinion, and one I would like some community
backing for before I espouse this as a "best practice" within my
organization. This might just be a matter of style, but I'm interested in
how other developers are determining this.