...
| Code Block | ||
|---|---|---|
| ||
<xsd:schema xmlns:xsd="http://www.w3.org/2001/XMLSchema" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" targetNamespace="http://doms.statsbiblioteket.dk/types/view/0/2/#" xmlns="http://doms.statsbiblioteket.dk/types/view/0/2/#" elementFormDefault="qualified" attributeFormDefault="unqualified"> <xsd:element name="views" type="viewsType"/> <xsd:complexType name="viewsType"> <xsd:sequence> <xsd:element name="view" type="viewType" minOccurs="0" maxOccurs="unbounded"/> </xsd:sequence> </xsd:complexType> <xsd:complexType name="viewType"> <xsd:sequence> <xsd:element name="relations" type="relationsType" minOccurs="0" maxOccurs="1"/> <xsd:element name="inverse-relations" type="inverse-relationsType" minOccurs="0" maxOccurs="1"/> </xsd:sequence> <xsd:attribute name="name" type="xsd:string" use="required"/> </xsd:complexType> <xsd:complexType name="relationsType"> <xsd:sequence> <xsd:any namespace="##any" processContents="skip" maxOccurs="unbounded"/> </xsd:sequence> </xsd:complexType> <xsd:complexType name="inverse-relationsType"> <xsd:sequence> <xsd:any namespace="##any" processContents="skip" maxOccurs="unbounded"/> </xsd:sequence> </xsd:complexType> </xsd:schema> |
Multilevel Views
...
Of course, it is very preferable to be able to have deeply nested views. Achiving this is easy. Above we defined the annotated relations as marking which objects should belong to the view. What we really meant was which object-views should be included in the view.
The formal definition of the semantic meaning of the relations in the "VIEW" datastream is therefore: Each data object has a view, encompassing the object and the views of other directly related data objects. So, if the VIEW datastream in a object was
| Code Block |
|---|
<view:views xmlns:view="http://doms.statsbiblioteket.dk/types/views/0/1/#"> |
...
<view:view name="GUI"> |
...
<view:relations> |
...
<doms:hasFile xmlns:doms="http://doms.statsbiblioteket.dk/relations/default/0/1/#"/> |
...
</view:relations> |
...
<view:inverse-relations> |
...
<doms:isPartOfCollection xmlns:doms="http://doms.statsbiblioteket.dk/relations/default/0/1/#"/> |
...
</view:inverse-relations> |
...
</view:view> |
...
</view:views> |
then the View of this object encompass the object itself, and the "GUI" View of any objects that the object has a "doms:hasFile" relation to and any object that has a "doms:isPartOfCollection" relation to this object.
The procedure to calculate the total view of a object is detailed in this bit of pseudo code. It basicly performs a depthfirst search of the objects. The order of the objects in the View does not carry any sort of meaning, and will be random.
| Code Block |
|---|
Set<Object> visitedObjects; |
...
...
List<Object> CalculateView(Object o) { |
...
List<Objects> view = new List<Objects>(); |
...
...
if (visitedObjects.contain(o){ |
...
return view; |
...
}
} visitedObjects.add(o); |
...
ContentModel c = o.getContentModel(); |
...
List<Relation> view-rels = c.getViewRelations(); |
...
List<Relation> object-rels = o.getRelations(); |
...
...
for (Relation r : object-rels){ |
...
if (view-rels.contain(r)){ |
...
view.addAll(CalculateView(r.getObject()); |
...
} |
...
}
...
} List<Relation> view-invrels = c.getInverseViewRelations(); |
...
List<Relation> object-invrels = o.getInverseRelations(); |
...
for (Relation r : object-invrels){ |
...
if (view-invrels.contain(r)){ |
...
view.addAll(CalculateView(r.getSubject()); |
...
} |
...
}
...
} return view; } |
}
Datastream View
The described view system can designate exactly which objects are part of a view. But it is not always enough to know just the objects. For the GUI, it is nessesary to know exactly which datastreams should be presented, and how. For this purpose we have designed an DS-COMPOSITE extension, which follows the system laid down in FedoraTypeChecking.
...