Topic: "DITAVAL-reference domain element"
- c/a DITAVAL file/a DITAVAL document/
- In the first paragraph the language is "conditions that apply only to a subset of a DITA map" but in the arch spec the language "map branch" or "branch of a map" is used consistently. Should probably rework these topics to use "branch" rather than "subset". In addition, <ditavalref> can apply to an entire map, so might be clearer to say "a map or map branch" rather than "only to a subset".
The first paragraph under the "<ditavalref>" uses "branch" as used in the arch spec, so it's correct.
Topic "<ditavalref>"
- c/ all resources that are referenced by the parent element or its children/ all resources that are referenced by the parent element or its descendants/ (c/children/descendants/)
- c/ appear before peer topic references/ appear before sibling topic references/ ("peer" in this context could be confused with scope="peer").
- c/ will use this convention/ use this convention/ (delete "will")
- c/if the example above contains/if the example above contained/
- c/as a peer/as a siblilng/
- Under "Limitations", Comment by robander This topic overall has far more processing information...
This information is in the arch spec and can be removed from this topic. Should be sufficient to remove the entire Limitations section and replace the reference to it with a link to the top-level branch filtering topic.
Likewise, the Processing expectations" are covered in the arch spec, so should not be here.
Topic "<dvrResourcePrefix>
- Comment by robander The ditavalmeta element refers to arch spec examples, that might be better here as well, given the new complexity of added resourceid elements:
Agree that the example should be moved to the main ditavalref examples topic. Ditto <dvrResourceSuffix> element topic.
Cheers,
E.
_____________________________________________
Eliot Kimber
Sr. Staff Content Engineer
O: 512 554 9368
servicenow
servicenow.com
LinkedIn | X | YouTube | Instagram