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

dita — archive

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

Groups - DITA Proposed Feature #12013 Referencing a range of elements (conrefrange.html) uploaded


Hi Yas, I've just got a few comments about the proposal before we have a meeting on it. Aside from what's below, I have an initial positive impression of Paul's suggestion to work purely with singletons, though I probably have not thought it through completely yet. 1) "The user must only create ranges on target elements that share the same parent element. " -- Does this mean that a source range inside can only be to a target inside ? Or does it just mean that the target start/end must be siblings and thus share the same parent node? I think it means the latter, but I know the former was discussed a while back. 2) The "Processing behaviors" section seems to state that the domains attribute on the source and target topics must be an exact match. That is more restrictive than the current restriction on conref, in which compatibility is guaranteed when "the list of domains in the referenced topic instance (declared on the domains attribute) is the same as or a subset of the list of domains in the referencing document" [1]. That is, when the source topic has domains="(topic hi-d) (topic sw-d)", target topic values of "(topic hi-d)" and "(topic sw-d) (topic hi-d)" should both be valid, but requiring an exact match would rule them out. The language here should match the existing language for single point conrefs. 3) I don't understand this comment: "Note: The current DITA Open Toolkit implementation does not perform validate beyond class and domain matching. It is already possible to include invalid content". The toolkit looks for a valid subset of domains, rather than an exact match - I think it has always done this, though it may have been added in an early release. 4) I also do not quite understand this: "Note: Generalizing on the fly, proposal 12012, has been deferred to DITA 1.3..." The specification today already says this about conref generalization, in the domains paragraph: "In the preferred approach, a processor resolving a conref should tolerate specializations of valid elements and generalize elements in the content fragment as needed for the referencing context." [1] Deborah Pickett contributed code to the toolkit that performs this generalization for domain elements -- when conref of a paragraph causes me to pull into a topic that does not allow highlighting, the is generalized to

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