OASIS Open Mailing List Archives  ·  All Lists  ·  dita  ·  2010-09

dita — archive

[Date Prev]  |  [Thread Prev]  |  [Thread Next]  |  [Date Next]   —  [Date Index]  |  [Thread Index]  |  [Month Index]  |  [List Home]

@domains Attribute Details


Per my comment and subsequent action to try to collect all the @domains specific rules in one place, I have combed the spec for any mention of the syntax details of @domains. Here is my analysis of the rules and where they are currently specified or alluded to: 1. For structural modules, the structural type hierarchy SHOULD be listed [2.1.4.2, 2.1.4.2.2, 2.1.4.3.1]: (topic concept) (map bookmap) [Side note: These declarations appear to be missing from the DTD versions of the specialized topic and map types but are in the XSD versions.] 2. If a structural type depends on one or more domains, those are listed following the structural type [2.1.4.3.8.1.3]: (topic concept myProgrammingConcept pr-d) The implication being that topic type myProgrammingConcept must always be integrated with the programming domain and uses one or more element types from the programming domain directly in myProgrammingConcept content models. 3. Each separately-integrated domain module is listed with its ancestor modules [2.1.4.3.8]: (topic pr-d) (topic pr-d cpp-d) (map mapgroup-d my-topicheads-d) 4. Constraint modules are listed with the structural or domain module they constrain [2.1.4.4.1]: (topic noMixedContentTopic-c) (map noReltable-c) Note: The current spec language actually says: The replacement text for the entity must be of the form "(tagname qualifierTagname-c)", where tagname is the name of the element type to which the constraints apply, qualifier is as for the module filename (e.g., "strict"), and Tagname is the element type name with an initial capital (e.g. "Topic") But I understand "tagname" in this context to mean "structural root type". Or is the intent that if a constraint module only constrains "p" then then the @domains spec would be "(p noMixedContentP-d)"? 5. Attribute domains list their ancestor attribute (@props or @base) and use "a(" to distinguish them from element-type modules [2.1.4.3.8.1.5]: a(props myPropsAtt) a(base myBaseAtt) I think this covers everything--have I missed anything? Technical Detail Question: In 2.1.4.4.2 there is this example:

[Date Prev]  |  [Thread Prev]  |  [Thread Next]  |  [Date Next]   —  [Date Index]  |  [Thread Index]  |  [Month Index]  |  [List Home]