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]