[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: RE: [dita] Groups - DITA Proposed Feature #12013 Referencing a range ofelements (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 <body> can only be to a target inside <body>? 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 <b> into a topic that does not allow highlighting, the <b> is generalized to <ph>. It *appears* that this sort of processing is a part of what's proposed in 12012, which is a bit confusing, given the existing spec wording. Maybe 12012 would have required the behavior, rather than suggesting it as the preferred approach? Other than that, I only noticed two typos. The link to proposal 12012 is incorrect, and most of the examples at the bottom use <of> instead of <ol>. Thanks - Robert [1] http://docs.oasis-open.org/dita/v1.1/CS01/archspec/conref.html Robert D Anderson IBM Authoring Tools Development Chief Architect, DITA Open Toolkit (507) 253-8787, T/L 553-8787 (Good Monday & Thursday) "Yas Etessam" <yas.etessam@justsystems.com> wrote on 09/25/2007 03:59:31 PM: > Well I'm glad to hear that the proposal is moving into a better > direction. Thank you for the useful feedback and suggestions. > > > With the singleton approach, I suggest we continue with > > "the first element in the source must be the same > > type as the start element of the target range" and > > the rest of the usual conref validation, but we don't > > do any such validation for the target of the conrefend. > > Great suggestion. After all, there's nothing for the conrefend to be > compared with in the singleton model. I agree that the recursive model > makes much more sense on the singleton model. > > > > -----Original Message----- > > From: Grosso, Paul [mailto:pgrosso@ptc.com] > > Sent: Tuesday, September 25, 2007 11:14 AM > > To: dita@lists.oasis-open.org > > Subject: RE: [dita] Groups - DITA Proposed Feature #12013 Referencing > a > > range of elements (conrefrange.html) uploaded > > > > > > > > > -----Original Message----- > > > From: yas.etessam@justsystems.com > > > > > > Document Description: > > > HTML version of DITA Proposed Feature #12013 Referencing a range of > > > elements > > > > > > Download Document: > > > > > http://www.oasis- > > open.org/apps/org/workgroup/dita/download.php/25393/con > > refrange.html > > > > > > I still have reservations about this proposal in general, > > but I think the singleton approach makes it more palatable. > > > > The singleton approach seems to have fewer problems, > > and I see no advantage to the paired approach. In > > particular, I think recursive conreffing with the > > paired design is problematic--I wouldn't want it to > > work as described in the current proposal where it > > sounds like a start conref can/must point to a start > > conref, etc. (There is no reason the beginning or > > end--or any of the intermediate siblings--of the > > referenced range couldn't be a pointwise conref.) > > > > With the singleton approach, I think we would have an > > easier time addressing various possible error cases. > > We might just be able to say something like "if the > > conrefend attribute's target is not found on a > > 'following sibling' (in the XPath sense) of the > > conref attribute's target, that conrefend attribute > > is ignored (with or without an error message), and > > the conref is treated as a usual (pointwise) conref" > > and have that cover all error cases. > > > > With the singleton approach, I suggest we continue with > > "the first element in the source must be the same > > type as the start element of the target range" and > > the rest of the usual conref validation, but we don't > > do any such validation for the target of the conrefend. > > > > paul
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]