[XML-DEV Mailing List Archive Home] [By Thread] [By Date] [Recent Entries] [Reply To This Message]

Default attribute values at a higher level element?

• To: xml-dev@l...
• Subject: Default attribute values at a higher level element?
• From: "Andrzej Jan Taramina" <andrzej@c...>
• Date: Tue, 5 Feb 2002 16:04:30 -0500
• Organization: Chaeron Consulting Corporation
• Priority: normal
• Reply-to: andrzej@c...

Sure could use some advice on how to handle this situation!  Thx!

Is there any preferred way to allow encoding of a changed default attribute 
value at a higher level element? 

For example: 

Say I have a instance fragment that looks like this: 

<GPSData>	
   <Waypoint>...</Waypoint>        
   <Waypoint>...</Waypoint>   
   <Waypoint>...</Waypoint>  
   <Waypoint UOM="other"> ...</Waypoint>  
<GPSData>

Where Waypoint has an attribute called UOM which defaults to the value 
"degrees". eg <Waypoint UOM="degrees"> is the default. 

Is there an good way to do specify the following in an XMLSchema: 

<GPSData defaultUOM="radians">	
   <Waypoint>...</Waypoint>        
   <Waypoint>...</Waypoint>   
   <Waypoint>...</Waypoint> 
   <Waypoint UOM="other"> ...</Waypoint>  
<GPSData>

And have the default UOM for each Waypoint EXCEPT the last now be 
radians? 

My gut feel is that you could only do this in the processing application, but the 
question is how? I'm showing my ignorance of DOM/SAX validating parsers 
here so please bear with me 

The problem I see is that a validating parser will build the tree using the default 
value of UOM (degrees) for all the Waypoints that do not explicitly specify a 
value.  But is there any way to check in an application program to know that 
this value was specified by default rather than explicitly and thus should really 
be "radians" as defined at the parent GPSData element level if it was allowed 
to default?  

Thanks for any insight you can offer. 
Andrzej Jan Taramina
Chaeron Corporation: Enterprise System Solutions
http://www.chaeron.com

• Prev by Date: RE: Namespace terminology
• Next by Date: RE: Categories of Web Service messages: data-oriented vs action-oriented
• Previous by thread: Namespace terminology
• Next by thread: Using <choice> to enforce rules
• Index(es):
  • Date
  • Thread