RE: Attributes vs. Elements for Code values

Not at all sure this is a good idea, but just to round out the options:

If you use elements (which I'm not necessarily recommending), you can do 
enumerations either as an enumerated simple type:

<car>
        <!--make is an enumerated simple type -->
        <make>Ford</make>
</car>

or as empty element content:

<car>
        <!--make contains a substitution group head -->
        <make>
                <Ford/>
        </make>
</car>

The content model for "make" might name a substitution group head, 
allowing only empty elements.  Now you have an idiom where items can be 
added to the substitution group without changing the definition of the 
head, or even doing any imports or includes (depending on how you use 
namespaces and how your processor gathers schema documents.)

I haven't tried this, but I believe it works.  Of course, it has many pros 
and cons as a style for modelling data, and it will affect the style of 
your downstream processing, of mappings to programming language 
structures, etc.  Still, I think it is an option you can consider.

------------------------------------------------------------------
Noah Mendelsohn                              Voice: 1-617-693-4036
IBM Corporation                                Fax: 1-617-693-8676
One Rogers Street
Cambridge, MA 02142
------------------------------------------------------------------







Simon.Cox@csiro.au
Sent by: xmlschema-dev-request@w3.org
04/16/03 10:47 PM

 
        To:     Jack@Ottawa.com, xmlschema-dev@w3.org, dvint@mindspring.com
        cc:     (bcc: Noah Mendelsohn/Cambridge/IBM)
        Subject:        RE: Attributes vs. Elements for Code values



If it is required to have schema-validation of codes then you have no 
choice
- they have to be part of an 'enumeration' (or maybe 'pattern') 
restriction
of the suitable base type. 

But this does not mean that the schema document that contains the
enumeration must be the "master" schema document.  It should probably be
factored out into a separate schema document, which is <include>d into the
master schema document.  Updates then only require you to distribute the
schema document containing the enumeration. 

OTOH if you want extensibility without validation, then anyURI is a likely
alternative - that way you can make the definition of the term available 
via
http. 

> -----Original Message-----
> From: Jack Lindsey [mailto:Jack@Ottawa.com]
> Sent: Thursday, 17 April 2003 10:12 AM
> To: xmlschema-dev@w3.org; Dan Vint
> Subject: Re: Attributes vs. Elements for Code values
> 
> 
> 
> Our general approach is to avoid enumeration within the 
> schema because we typically have way more than a handful of 
> values, often 30 or so, even a couple of thousand for car 
> make and model.  So we wanted to keep code value maintenance 
> independent from schema maintenance since we anticipate 
> issuing code table updates more frequently than schema updates. 
> 
> Cheers jack
> 
> ----- Original Message ----- 
> From: "Dan Vint" <dvint@mindspring.com>
> To: <xmlschema-dev@w3.org>
> Sent: Wednesday, April 16, 2003 9:33 PM
> Subject: Re: Attributes vs. Elements for Code values
> 
> 
> : 
> : My organization has 2 schemas one with each approach. The 
> issue is somewhat 
> : of a wash until you consider if you are providing an 
> enumerated list of 
> : values. We have found it to be more flexible to have this 
> as element 
> : content than as attribute content.
> : 
> : Originally coming from SGML, I would have pushed the 
> attribute route 
> : because a DTD allowed some validation and control of a 
> defined list where 
> : element content didn't. Schemas change that and allowed 
> both the manage 
> : this issue, now it seems to be how you might want to extend 
> a list of 
> : values that settle the discussion.
> : 
> : 
> : At 09:09 PM 4/16/2003 -0400, Jack Lindsey wrote:
> : 
> : >I want to use XML attributes to hold terse code values 
> (e.g. "CA-BC", 
> : >"312120", "23") that are replaced by text in the language 
> of your choice 
> : >from lookup tables in XML files (e.g. 
> : >"Colombie-Britannique",  "Breweries", "Cul-de-sac") when 
> the XML data is 
> : >rendered on a web page.  However, some of my colleagues 
> suffer from 
> : >generalized attribute phobia and want to do everything with XML 
> : >elements.  I don't see the danger.  Here are my pros and 
> cons.  What do 
> : >you think?
> : >
> : >
> : >PRO
> : >1. Attributes mean much more compact XML data
> : >2. Processing attributes is much more efficient in XSLT and DOM
> : >3. Everybody does codes this way
> : >
> : >CON
> : >1. Other people's schemas can't just reuse your codes 
> without also using 
> : >the surrounding element, unless you declare your code 
> attributes globally? 
> : >Is that right?
> : >2. If an element can have multiple values of a code (like 
> Disability in 
> : >Being in the example below), you have to create an element 
> for it anyway 
> : >so it can occur multiply, and that is the worst option, 
> performance-wise 
> : >(according to Scott Bonneau, XML Design handbook, p. 43)
> : >3. You don't get that nice XML schema diagrammatic 
> documentation for your 
> : >attributes in XML Spy.
> : >
> : >
> : >Sample Data:
> : >
> : ><Being beingSerialNumber="0002345" genderID="3" speciesID="42">
> : >   <BeingBirthDate>1980-04-13</BeingBirthDate>
> : >   <Disability disabilityID="17"/>
> : >   <Disability disabilityID="24"/>
> : >   <MedicalConditionNarrative medicalConditionID="23">Not 
> responding to
> : >treatment.</MedicalConditionNarrative>
> : >   <MedicalConditionNarrative medicalConditionID="16">Clearing up
> : >nicely.</MedicalConditionNarrative>
> : ></Being>
> : >
> : >Cheers Jack
> : 
>

Received on Thursday, 17 April 2003 10:34:15 UTC