OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.


Help: OASIS Mailing Lists Help | MarkMail Help



   Re: [xml-dev] XML Schema question on key, keyref constraints

[ Lists Home | Date Index | Thread Index ]

Bob Foster wrote:

> Key/keyref seem well-suited to describing elements that can be 
> "flattened" into relational tuples, not so good for true hierarchies. 

I disagree with this statement. For our purposes, we have found 
key/keyrefs to be very useful for hierarchies. Let me explain.

We have an ASP (webapp) based content management system. We manage 
several projects at one time on our servers. This is greatly aided by 
XML configurations; for simplicity they are:

  Global level

- projects.xml
- users.xml

  Project level

- site.xml - an hierarchical representation of a website/project, used 
to create a brochure-type site

- topics.xml[1] - an hierarchical representation of topics and content, 
used to create a dmoz-like site

- groups.xml - an hierarchical representation of the project's groups so 
  groups of users can be assigned roles at the node level in both the 
site.xml and topics.xml

- xsl.xml - maps out layout regions available and a listing of 3 types 
of XSLs:
    - primary or main source in a transformation
    - basic includes
    - 'components' are things like TOC, snailtrail, metadata, etc that 
can be triggered through the site.xml configuration

A project can be assigned users. The project users reference users in 
users.xml. A site idref references a project in projects.xml. Group 
users reference users in the users.xml and projects.xml.

In the site.xml there are a several places where keys/keyrefs are used. 
Here is an simplified example of a site.xml:

<site css="default.css" id="site_root" name="robbie" 
index_page="site_ind" onnav="0" xsl="default">
   <label>a label</label>
   <title>The  base site title</title>
   <page id="site_ind" .../>
   <folder onnav="1" css="inherit" id="F991626" xsl="inherit" expand="1" 
name="folder_F991626" pager="1" snailtrail="1" index_page="P15691">
     <label>folder 1</label>
     <title>Folder 1</title>
       <region name="narrow_col">
         <content ref="a1888955664"/>
     <page generate="1" onnav="1" css="inherit" id="P15691" 
xsl="inherit" name="cool_name.html" pgstatus="hold" print_friendly="1">
       <label>p 1</label>
       <title>P 1</title>
           <region name="wide_col">
              <component ref="toc"/>
             <content ref="a1888955664"/>
             <content ref="a1834783457"/>
     <page generate="1" onnav="1" css="inherit" id="P366837" 
xsl="inherit" name="nice_name.html" pgstatus="hold" print_friendly="1">
       <label>p 2</label>
       <title>P 2</title>
           <region name="wide_col">
              <component ref="metadata"/>
             <content ref="a72345775"/>

In the above you may notice that the folder|site/@index_page references 
a page/@id. The page|folder|site/@xsl references a primary XSL detailed 
in the xsl.xml. A regions/@name (basically a html:div/@id in the 
rendering) references a region defined in the xsl.xml. component/@ref 
references a component defined in the xsl.xml. content/@ref references a 
content piece in topics.xml.

The content pieces themselves might contain internal links; they 
reference a page id in the site.xml.

Using the above relationships in key/keyrefs has been a great benefit 
for us in keeping projects manageable. It allows us to change XML 
configs and XSL with 'upgrade' transformations and ensure the projects 
will still work.

I think the key/keyrefs are very useful for hierarchies.


[1] I have never understood why *real* Topic Maps are flat. For example 
the faceted classification pattern seems like an anti-pattern to me.

> Bob


News | XML in Industry | Calendar | XML Registry
Marketplace | Resources | MyXML.org | Sponsors | Privacy Statement

Copyright 2001 XML.org. This site is hosted by OASIS