[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 of elements (conrefrange.html) uploaded
Yes, the intent is to match the same processing rules as single point conref. Deborah asked for more information about processing to be explicitly spelled out in the proposal. Maybe it is appropriate to cut that back down to a core assumption about inheriting similar processing rules, rather than my poor (and clearly inaccurate) attempt to describe the actual processing rules. > -----Original Message----- > From: Grosso, Paul [mailto:pgrosso@ptc.com] > Sent: Thursday, September 27, 2007 10:48 AM > To: dita@lists.oasis-open.org > Subject: RE: [dita] Groups - DITA Proposed Feature #12013 Referencing a > range of elements (conrefrange.html) uploaded > > fwiw, a couple comments from me on Robert's email below. > > > -----Original Message----- > > From: Robert D Anderson [mailto:robander@us.ibm.com] > > Sent: Thursday, 2007 September 27 11:34 > > To: Yas Etessam > > Cc: dita@lists.oasis-open.org > > Subject: RE: [dita] 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 <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. > > I think it means the latter, and this is irrelevant if we > go with the singleton model (which is one big advantage of > the singleton model). > > > > > 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. > > I agree that we should (and, I assumed, meant to) match what > happens for single point conrefs in this regard. > > paul
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]