dynamiclist.dtd: Elements - Entities - Source | Intro - Index

<?xml version="1.0" encoding="ISO-8859-1"?>


     The XML defined after this document describes which query to make and how
     to display its results. The query is defined under the query tag.
     Here is an example :
        <query repository="\%\bbackgrounder" numberitems="3">
            <filter type="includes" tagName="usertype">
            <sort order="ascending" tagName="harvestdate"/>
     One reads it this way :

        The query will be made upon the backgrounder repository. Therefore,
        the query will give some backgrounders as a result. The result
        set will contain at most 3 backgrounders, sorted upon their
        harvest date, in a ascending order. The selected backgrounders are
        those of which the usertype tag includes the gues value.

     It is a rather straightforward explanation. Basically, the query works
     as a filter. All the content items of the given repository for the current
     site are filtered out according to the "filter" tag. The type of the
     filter indicates what to check for. Usually filter should always work
     list is intended for the homepage, this component won't be able to
     display complex content or big content. It is rather intended to
     display a few information taken out of each of the items returned by
     the query. Let's look at an example.
        <display template="template2">
            <map tagName="title" holeName="a"/>
            <map tagName="harvestdate" holeName="b"/>
     One reads it this way :

         Each of the item will be displayed according to the template
         "template2". Once displayed, the holes in the template will
         be replaced by values taken from the items returned by the

     Before rereading the explaination, here are the different standard
     templates :


     So as said above, the templates will be used to display each item.

     @title Dynamic List Box
     @hidden somethings should never be told. But everybody should
       know them.
     @root dynamiclist -->

<!-- Dynamic list top node. -->

<!ELEMENT dynamiclist (version, country+, language, author, itemname, site+, topic*, source, usertype+, publishdate, harvestdate, title, abstract, query, display)>

<!-- Names of the content tags recognized by the system. The recognized
     tags are those declared by the item descriptors. Of course, some
     tags are recognized for some (and only some) content, making this
     list erroneous. But this validation is still better than nothing
     (it validates syntax, not semantic). -->

<!ENTITY % recognizedContentTag "(title | topic | harvestdate | usertype)">

<!-- The query part describes how to retrieve the results from the repository
     to display.

     We could have made it closer to the targeter definition but then it'd
     be too complicated for an end user. However, as functionality will be
     extended, it'd be nice to keep in mind that getting closer to Dynamo's
     way of describing queries will make the transformation of this XML
     into 'real' queries easier. -->
<!ELEMENT query (filter, sort)>

<!--  @attr @attr aaaa @attr repository The repository on which to apply the query. It is an attribute so that we
     get instant validation through DTD. As a naming convention, the
     repository name is the one of the corresponding RepositoryName property
     of the repository. So for example for the backgrounders,
     we'll use the name "BackgroundersRepository" because the repository
     property defined in /configurations/common/repositories/backgrounders/BackgroundersRepository.properties
     is such.

     This will allow to build a automatic (configuration-less) mapper.

     @attr numberitems The maximum number of items returned by the query to display. -->

<!ATTLIST query
    repository (backgrounder) #REQUIRED
    numberitems (1 | 2 | 3 | 4 | 5) "1"

<!-- The filter describes which items to retrieve from the repository.
     Basically, it states a condition that each item must satisfy to be part
     of the result set. A filter might need several parameters. -->
<!ELEMENT filter (parameter)>
<!-- A parameter to the filter. For example  a filter can ask to get
     elements belonging to a list.-->
<!ELEMENT parameter (#PCDATA)>
<!ATTLIST filter
    type (includes | equals) #REQUIRED
    tagName %recognizedContentTag; #REQUIRED

<!-- Tells on which tag to sort the content. Please note that the tag must
     be reachable by Dynamo as a property. Therefore, its definition must
     appear in the "itemdescriptors". Please note that it doesn't make sense
     to sort on multi-valued tags.

     The sort information have been put in a separate element to allow
     for a sort on several tags (we could have given all the tags in a
     coma separated list but then we would have lost the DTD validation
     capabilities. -->


<!-- Tells in which order to sort. -->
<!ATTLIST sort order (ascending | descending) "ascending">

<!-- Tells on which item's tag to sort. -->
<!ATTLIST sort tagName %recognizedContentTag; #REQUIRED>

<!-- The display tag describes how each item will rendered. Right now, the
     items are assumed to be displayed one below each other. -->
<!ELEMENT display (map+)>
<!-- Selects which template to be used for the display. Several are
     available.  -->
<!ATTLIST display
    template ( template1 | template2 | template3 | template4) "template1"
<!-- Each template has holes to be filled, named a,b,c,... The map tags
     tell what value to put in each hole.

     This tag is only defined by attributes right now. -->
<!-- The name of the tag of which the value must be put in a given hole. -->
    tagName %recognizedContentTag; #REQUIRED
<!-- The name of the hole to fill in the template. -->
    holeName (a | b | c) #REQUIRED

<!ELEMENT alpha (#PCDATA)>
<!ELEMENT beta (alpha,alpha)+>
<!ELEMENT gamma (beta,beta)+>

<!ELEMENT phi (beta,beta,beta,(beta|beta))+>

<!ELEMENT ksi (#PCDATA|zeta|rho)*>

<!ENTITY % common_cms SYSTEM "common/common_cms.dtd">