XML That Pays Off for Your Content Database

1. XML That Pays Off for Your Content Database “It’s all about the content.” Lisa Boswww.reallysi.com

2. This year’s theme: Context • This year’s 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 • <conf> <name>InfoToday 2002</conf-name> <date>20020515</date> …</conf> • Hierarchical • DTDs/schemas (tags and attribute rules) • Basic concepts • Meaningful names • Rules-based (= consistency) • Format-independent and predictable

5. Introduction • If you’re confused about how or whether to combine XML with databases, you’re 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: 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 Documents and data

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. Interchange (data loading, publishing, integration, …) Storage Editing 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) • Yesterday’s and most of today’s 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, it’s 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, it’s 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 (cont’d) • 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 doesn’t 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 don’t.

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 • It’s 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 isn’t a firm line. • Be pragmatic – you probably need to choose an approach based on what’s 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.