Cart
[Home] [By Thread] [By Date] [Recent Entries]
Yes - all great points (thank you to everyone!). I also think that one disadvantage to approaches #2 and #3 (from the original e-mail - these approaches used attributes) is that using purely W3C Schema, it is not possible to enforce mandatory/optional if, given the value of the attributes, the entire "set" (element/attributes/values) may be considered mandatory in some cases, but optional in others (according to the data requirements. To illustrate, I will remind us of approach #3: <FinalEstimatedAmount yearType="CurrentYear" amountType="Budget"> >999.99</FinalEstimatedAmount> If instead of this approach, one used purely elements (as with approach #1) and the difference between 2 element names were according to the "yearType" attribute, one would have the following 2 uniquely named elements (using pipes to seperate sub-components): (1) CurrentYear|Budget|Final|EstimatedAmount (2) PriorYear|Budget|Final|EstimatedAmount If in a given content model, element (1) above were mandatory and (2) were optional, that is of course easy to enforce. However, with approach #3, there would be no way to enforce this using *purely W3C Schema* (we know RELAX NG and Schematron can) - we cannot enforce that "FinalEstimatedAmount" is mandatory when yearType="CurrentYear", etc. One would need to make the "FinalEstimatedAmount" optional as a "lowest common denominator" approach, which doesn't meet the requirement. Thanks, Joe Jonathan Robie wrote: > > At 06:12 PM 4/3/2003 +1000, Rick Jelliffe wrote: > >You can have your cake and eat it too, Marie Antoinette not > >withstanding. > > > >For example, > ><!ATTLIST cybfea > > fullname CDATA #FIXED "CurrentYearBudgetFinalEstimatedAmount" > > type CDATA #FIXED "Amount" > > yearType CDATA #FIXED "CurrentYear" > > amountType CDATA #FIXED "Budget" > > finalIndicator CDATA #FIXED "Final" > > estimateIndicator CDATA #FIXED "Estimated" > > > > > > >means that the markup of > > > ><cybfea>999.99</cybfea> > > > >implies the infoset of > > > ><cybfea fullname="CurrentYearBudgetFinalEstimatedAmount" > > type="Amount" > > yearType="CurrentYear" > > amountType="Budget" > > finalIndicator="Final" > > estimateIndicator="Estimated" > > >999.99</cybfea> > > Of course, there is a cost to this approach as well - in some environments, > users like to look at their markup and write queries or programs based on > what they see in the instance. With Rick's approach, most of the action is > precisely in the things you can't see when looking at the instance > document. On the other hand, it conveys the information you need very > compactly if the size of the markup matters in your environment. > > Again, it's best to figure out how the data will be used so you know which > factors are important to optimize. Design is a kind of optimization, and > you can't design until you know what you are trying to optimize. > > Jonathan > > ----------------------------------------------------------------- > The xml-dev list is sponsored by XML.org <http://www.xml.org>, an > initiative of OASIS <http://www.oasis-open.org> > > The list archives are at http://lists.xml.org/archives/xml-dev/ > > To subscribe or unsubscribe from this list use the subscription > manager: <http://lists.xml.org/ob/adm.pl> begin:vcard n:Chiusano;Joseph tel;work:(703) 902-6923 x-mozilla-html:FALSE url:www.bah.com org:Booz | Allen | Hamilton;IT Digital Strategies Team adr:;;8283 Greensboro Drive;McLean;VA;22012; version:2.1 email;internet:chiusano_joseph@b... title:Senior Consultant fn:Joseph M. Chiusano end:vcard
|
