Home. 
.

transparent

transparent

transparent

Altova Mailing List Archives


RE: [xml-dev] can attribute in XML schema hold value and unit

From: "Bullard, Claude L \(Len\)" <len.bullard@----------.--->
To: "Sreeni Yetchina -X \(syetchin - Pure Solutions at Cisco\)" <syetchin@-----.--->,"Mangesh Kalbhor" <Mangesh.Kalbhor@--------.--->,<xml-dev@-----.---.--->
Date: 3/3/2006 8:45:00 PM
Correct.  Where there is no choice, that works.   Regex is 
essentially microparsing and you can 
do 
that anywhere in the pipeline with regex or even string testing in 
script.   
 
From a 
general design perspectiveas a producer, If I knew that was coming 

I'd 
try to do these tests prior to getting to the xml if possible.  Validation 
is a pretty 
good 
late binding test but sometimes that is too late.  Context makes all the 
difference, 
so if 
I know I am late binding, I prefer a correct-by-construction approach (eg. do it 
in 
the 
database client prior to emitting the XML) and weaken the 
dependence on validation. 
On the 
other hand, if one is the consumer, one probably has no choice and now regexing 

is 
attractive because it localizes the test.
 
len

  -----Original Message-----
From: Sreeni Yetchina -X (syetchin 
  - Pure Solutions at Cisco) [mailto:syetchin@c...]
Sent: Friday, 
  March 03, 2006 2:31 PM
To: Bullard, Claude L (Len); Mangesh Kalbhor; 
  xml-dev@l...
Subject: RE: [xml-dev] can attribute in XML 
  schema hold value and unit


  From the design perspective, I agree with 
  "Len".
  The best is to separate these two values(numerical and 
  units) . But this is possible if you are starting the Schema 
  afresh.
  but if the XML instance documents are already existing 
  and we need to write a Schema for them and some how to validate, we can follow 
  the method that I narrated in my last email(defining a regular expression 
  constraint on the Simple type of attribute definition in the 
  schema)
  Thanks,
  Sreeni

  
  
  From: Bullard, Claude L (Len) 
  [mailto:len.bullard@i...] 
Sent: Friday, March 03, 2006 
  12:24 PM
To: Mangesh Kalbhor; 
  xml-dev@l...
Subject: RE: [xml-dev] can attribute in XML 
  schema hold value and unit


  
   
  <FlowRate unitStuff="GPM 100" />
   
  The 
  best answer is, don't do that; it's bad design for 
  reasons that are obvious (esentially, it is a token delimited 
  
  list 
  and has all the same problems of production order, 
  catching errors late, all strings, etc.)
   
  Make 
  two attributes: one for unitType and one for unitValue.  
  
   
  <FlowRate unitValue="100" unitType="GPM" 
  />
   
  It's clear and better for production and 
  validation.
  
  If 
  these are basic types, say enumeration for the 
  unitTypes and numbers for the values, attributes will work 
  
  but 
  are the least extensible.
   
  A FlowRate element with an enumerated 
  attribute for unit type.
   
  <FlowRate unit="GPM">100</FlowRate>
   
  Dealer's choice but the last one is the most 
robust.
   
  len
  
    -----Original Message-----
From: Mangesh Kalbhor 
    [mailto:Mangesh.Kalbhor@a...]
Sent: Friday, March 03, 2006 
    2:08 PM
To: xml-dev@l...
Subject: [xml-dev] can 
    attribute in XML schema hold value and unit


    
    Hi 
    All,<o:p></o:p>
    <o:p> </o:p>
    I am creating a xml schema where 
    I have to making a ‘attribute’ but can a attribute hold a value and 
    unit.<o:p></o:p>
    My example is FlowRate, let’s 
    the value and unit could be 100 GPM.<o:p></o:p>
    Can I have just one attribute 
    for 100 and GPM both. Some times it might be 80 
    cFPS.<o:p></o:p>
    <o:p> </o:p>
    So can a attribute hold both or 
    do I need element here.<o:p></o:p>
    <o:p> </o:p>
    Thanks,<o:p></o:p>
    <o:p> </o:p>
    Mangesh<o:p></o:p>


transparent
Print
Mail
Like It
Disclaimer
.

These Archives are provided for informational purposes only and have been generated directly from the Altova mailing list archive system and are comprised of the lists set forth on www.altova.com/list/index.html. Therefore, Altova does not warrant or guarantee the accuracy, reliability, completeness, usefulness, non-infringement of intellectual property rights, or quality of any content on the Altova Mailing List Archive(s), regardless of who originates that content. You expressly understand and agree that you bear all risks associated with using or relying on that content. Altova will not be liable or responsible in any way for any content posted including, but not limited to, any errors or omissions in content, or for any losses or damage of any kind incurred as a result of the use of or reliance on any content. This disclaimer and limitation on liability is in addition to the disclaimers and limitations contained in the Website Terms of Use and elsewhere on the site.

.
.

transparent

transparent