XML That Pays Off for Your Content Database

1
XML That Pays Off for Your Content Database

• Its all about the content.
• Lisa Boswww.reallysi.com

2
This years theme Context

• This years Knowledge Management track focuses on
  context.
• XML, together with a database, is an excellent
  way to capture content context.
• Choosing when to use XML and among the tools for
  managing XML is also about context
• Content lifecycle context
• Organizational context

3
Audience survey

• Hands on experience with XML?
• Theoretical knowledge of XML?
• Little or no familiarity with XML?
• Organization using XML now?

4
XML basics

• What it looks like
• ltconfgt ltnamegtInfoToday 2002lt/conf-namegt
  ltdategt20020515lt/dategt lt/confgt
• Hierarchical
• DTDs/schemas (tags and attribute rules)
• Basic concepts
• Meaningful names
• Rules-based ( consistency)
• Format-independent and predictable

5
Introduction

• If youre confused about how or whether to
  combine XML with databases, youre not alone
• Today, few people are confused about the value of
  relational databases.
• Getting there with XML is more difficult because
  relational databases and XML are both
  complementary and overlapping.

6
Documents and data

• Documents
• Longer
• Internal structure
• Usually meant to be read from top to bottom
• Often used to support data

• Data
• Shorter (fields)
• Little if any internal structure
• Often used to support documents (metadata)
• Sometimes a collection of data presented as a
  document

7
Data and documents

• Your documents might contain data
• Financial reports
• Your data might contain mini-documents
• Long descriptions
• Reality a continuum of content
• Labels are for our convenience

8
Why differentiate data documents?

• Labels imply tools and functionality
• Think about what you do with Excel versus what
  you do with Word
• Especially important to
• Storage and searching
• Editing tools (forms and document editors)
• Interchange (sharing content among systems and
  organizations)
• Yesterdays and most of todays tools are
  optimized for one type of functionality

9
Uh oh

• But what about this continuum of content? How do
  I handle that?
• Figure out the best way for you (today) to
  support the functionality you need in each of the
  three main areas mentioned in the previous slide

10
Generally speaking When to use XML?

• XML is often a good choice for document capture.
• In general, its easier to model document
  structures hierarchically if you need to model
  them at all.
• XML is sometimes a good choice for data storage.
• In general, its easier to model data
  relationally.
• Context (lifecycle stage) is critical in
  determining architecture.

11
Storage searching options for XML/data

• Relational databases
• Optimization for complex data queries
• Mature
• Most databases or development platforms have some
  XML awareness
• Some ability to search XML
• Can write software to deconstruct XML and store
  it as fields in a database, and then to
  reconstruct for output as XML
• Performance okay
• Not as easy as it sounds

12
Storage and searching options for XML/data
(contd)

• XML databases
• Optimized for searching XML hierarchies
• Some ability to handle more relational content
• Might mean you choose to embed metadata within
  your XML documents
• Less mature
• Combination approaches
• Relational database and an XML database
• XML chunks in a relational database
• File system

13
Editing options for XML/data

• Forms
• Custom
• Can include text boxes
• Can include text boxes with XML support
  (functional limitations)
• Very easy to make available over the Web
• XML editors
• Provide both a document and a forms presentation
• Built in document editing and XML handling
  features
• More difficult to make available over the Web
• More expensive
• Word processors Lots of customization
• Combo Different tools for different content

14
Interchange options

• Lots of options. For example
• Database replication
• Data as XML (files or via software) is loaded
  into another database that understands more about
  the data relationships than is reflected in the
  XML
• Application level interchange that doesnt
  involve XML at all
• Tailor approach to the needs of the systems
  involved

15
Summary

• Do you need to control document elements?
• XML for documents worth considering.
• Is editing/presenting subsets of a document
  important?
• XML for documents, XML databases worth
  considering.
• Is searching specific document elements important
  to you?
• XML database worth considering.
• Do you have complex data relationships?
• Use a relational database (with an XML database?)
• Is your organization risk-averse?
• Stick with relational databases.

16
Aside 1 Wait a minute! XML for documents? Do I
have to?

• No, you dont.

17
Aside 2 Transformation

• To move between the three areas discussed
  storage, editing, and interchange content must
  be transformed
• This is more work than you might expect
• Its easier when your content is well-modeled
• Look very closely at the tools for transformation
  in prospective systems

18
Final Words

• Model your content first. Actively decide what
  the line is between data and documents in your
  environment or that there isnt a firm line.
• Be pragmatic you probably need to choose an
  approach based on whats possible, affordable,
  and acceptable (risk), not just architecturally
  appealing.
• Experiment and learn before making final choices.
• If you get the content right, you can change your
  implementation later.

19

• Thank you.