September 18, 2007 

Shahram Orandi 

Image Group 

XML Schema and Validatio

Approaches 
What’s on the menu... 

• Brief look at origin of markup languag• XML validation approaches and origin• Benefit / pitfall comparison 
A Brief Look at History 
Everything that has happened so fa

• First...there was GML (~1960s) • Then came SGML...(~1980s) • Then came XML (~1990s) 

– Initial Standard Included Basic Validation 

• Then came XML Schema (2001) 

– Offered Better Validation 
Markup Languages 

• A traditional text data stream may look 

this: 

John Doe 65000 (14 bytes 

• This same data stream when marked u

look like this: 

<employeename>John Doe</employeena<salary>65000</salary> (60 bytes 

• Cost is higher, but benefits are many 
Validation 
Validation 

• How can we make sure salary is valid? 

<salary>65000</salary> 9<salary>$65000</salary> ? 

<salary>65000.00</salary> ? <salary>65k</salary> ? 
Popular Validation Options in the Ear

• Standard: XML DTD (Document Typ

Definition), part of the XML 1.0 spec. 

• Proprietary: Write your own code or C
DTD (Document Type Definitio

• DTD is part of the XML spec, but limited

... 

<!ELEMENT employee (name,salary)> <!ELEMENT name (#PCDATA)> <!ELEMENT salary (#PCDATA)> 

... 

Where #PCDATA = parsed character data 

(string) 

• Basically checks if something is there or n
Code it Yourself 

• Write your own validation code 

If IsCurrency(sSalary$) and

val(sSalary$)> 0 andval(sSalary$)< l_MaxSalary then return True 

else 

return False 

endif 

• It takes lots of code to validate data 
Then Came XML Schema 

• Ratified a few years after 1.0 spec • Both XML Schema and DTD allow: 

Element nesting, attribute types/defaulelement occurrence constraints. 

• XML Schemas adds much more: User 

defined types, namespaces, better data constraints, etc. 
Salary Validation Revisited 

• Lets tighten up the rules with XML 

Schema: 

<xs:attribute name="salary" type="xs:integer"> 

<xs:annotation> 

<xs:documentation>Specifies a salary.</xs:documentation> 

</xs:annotation> 

</xs:attribute> 
How strict do you want to be? 

• What if someone sends over the wire 

“65000”? Or “65000.01”? 

• We could loosen rules a little: 

<xs:attribute name="salary" type="xs:decimal"> Allows “65000” or “65000.01” 

• Or relax things completely... <xs:attribute name="salary" type="xs:string"> 

Allows “65000”, “65000.00”, “$65000” or “65k”... but everything come through as well... 
Validation Challenges 
Validation Challenges: Off-Spec D

• Would ideally be relaxed enough to allow v

but-off-spec transactions that otherwise wourejected with strict validation: 

65000 ok! 65000.00 ok! $65000 ok! 

• Too lax and you may allow ambiguous or 

incorrect transactions through as well: 

You might let “-65000.%” through 
Validation Challenges: Mapping Asym

Conventional(Legacy) XML Standa

1  

Í

Î



(Easiest Case, One to One Mapping... Life is good!) 

2 



Í? ?

Î



(XML side is superset of legacy, will you accept legacy transactio

3 



Í? ?

Î



(Legacy is a superset, will you keep extra info? reject transaction
Looking at some options 

XML + No Validation: Not going to happen. • What it is: Hope all data coming down the w

was constructed properly, cross fingers. 

• Benefits: 

– Not much... maybe some development time sav

• Pitfalls: 

– Format errors, missing/ambiguous data, disaster

grand scale. 
Looking at some options (cont’d

XML + Custom Code Validation • What it is: Build your own validation into b

logic to verify data 

• Benefits: 

– Flexibility, genetic diversity 

• Pitfalls: 

– Redundant work, genetic diversity, as rules chan

need to keep up, lots of effort (code) 
Looking at some options (cont’d

XML + DTD • What it is: A liberal contract on data format 

structure 

• Benefits: 

– Simple, standard, centralized 

• Pitfalls: 

– Simple (limited)... Much of higher level validati

to be implemented in redundant code 
Looking at some options (cont’d

XML + XML Schema • What it is: A contract (liberal or strict) on d

format and structure 

• Benefits: 

– Comprehensive, centralized, saves code 

• Pitfalls: 

– Going too strict can cut certain parties ou

lock everyone in... (continued on next sl
Lax vs. Strict 

Benefits: Benefits: • Allows off-spec 

transactions through. 

• Provides some tolerance 

for slight changes due to improvements in technology or precision. 

Pitfalls: • May allow incorrect or 

ambiguous data through. 

• May muddy the database 

as more and more off-spec data is enrolled. 

• Puts greater burden on 

individual implementations for higher-level error checking. 

More Strict 

Less Strict 

• Ensures 

data, fac

• Reduces 

validatiocore app

Pitfalls: • Greater 

rejecting (some ooff-spec 

• Any cha

underlyiimprovetechnolonew (up
Partings thoughts... 

• Prepare to be open minded on validation app

after an XML data standard has been agreed 

• Try to think about what we can and can’t liv

early in the process of defining strictness. 

• There are some lessons learned by other 

enterprises in going to XML (HL7) that may helpful to examine. 

• Genetic diversity in the user population can 

strength not a weakness, but can push limits inter-op. Try to build in some flexibility. 
Q&A / Contact Info 

Shahram Orandi 

NIST Image Group 

sorandi@nist.gov