Conversation
azaroth42
requested review from
JulieWinchester,
kirschbombe,
mikeapp,
mixterj and
tomcrane
kirschbombe
left a comment
kirschbombe
left a comment
There was a problem hiding this comment.
Just a few suggestions for clarity and flow...
source/presentation/4.0/model.md
Outdated
| Need to cover: | ||
|
|
||
| Clients supporting dynamic content need to support | ||
| Collections are intended to be navigational constructs across the member collections and manifests, which are separate resources on the web. As Collections can be included as members of other Collections, this forms a hierarchy, and as a single collection can be included in multiple higher level Collections, it forms a polyhierarchy, where Manifests are the leaf nodes. |
There was a problem hiding this comment.
Could be easier to read - maybe: Collections can be included as members of other Collections, forming a hierarchy. Because a single Collection can belong to multiple higher-level Collections, this hierarchy becomes a polyhierarchy, with Manifests as the leaf nodes.
source/presentation/4.0/model.md
Outdated
| breaking change | ||
| anno `body` => Ordered List, redefine in context | ||
| will break any `"body": {}` annos | ||
| The Manifest has an `items` list of Containers. The default and most common scenario is that this list is the only structure for navigation, and all views are listed in the correct order. The navigation for a Manifest without any ranges is thus to allow the user to step through, and perhaps jump around in, this list. |
There was a problem hiding this comment.
maybe: "The Manifest has an items list of Containers. In the default and most common scenario, this list is the sole navigational structure, with all views listed in the intended order. With no ranges present, navigation should simply allow the user to step through, or skip around in, this list." - not sure we need to mention ranges here though?
source/presentation/4.0/model.md
Outdated
| will break any `"body": {}` annos | ||
| The Manifest has an `items` list of Containers. The default and most common scenario is that this list is the only structure for navigation, and all views are listed in the correct order. The navigation for a Manifest without any ranges is thus to allow the user to step through, and perhaps jump around in, this list. | ||
|
|
||
| Ranges provide alternative ways to navigate between and within the containers. A typical use case is a hierarchical, rather than flat, table of contents in which containers and parts of containers are grouped together into sections. If there is a `structures` field in the Manifest, then the Range instances within it provide additional navigational structures. A Range with the `behavior` value of `sequence` provides an alternative ordering, and a range with `no-nav` is not to be rendered in the hierarchy. |
There was a problem hiding this comment.
maybe: "....Ranges are defined in the structures property of the Manifest, where each Range instance provides an additional navigational structure. A Range with the behavior value of sequence provides an alternative ordering, and a Range with no-nav is not to be rendered in the hierarchy."
Also, "Range" or "range"? both are used so we should just be consistent.
3 participants
Add section on the processing model at end of the model file.