[
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>
<regions>
<region name="narrow_col">
<content ref="a1888955664"/>
</region>
</regions>
<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>
<regions>
<region name="wide_col">
<component ref="toc"/>
<content ref="a1888955664"/>
<content ref="a1834783457"/>
</region>
</regions>
</page>
<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>
<regions>
<region name="wide_col">
<component ref="metadata"/>
<content ref="a72345775"/>
</region>
</regions>
</page>
</folder>
...
</site>
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.
best,
-Rob
[1] I have never understood why *real* Topic Maps are flat. For example
the faceted classification pattern seems like an anti-pattern to me.
http://www.techquila.com/tmsinia5.html
>
> Bob
>
|
