[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
> -----Original Message----- > From: Robert D Anderson [mailto:robander@us.ibm.com] > Sent: Thursday, September 27, 2007 9:34 AM > 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. > Yes, it is the latter. The target start and end siblings need to be siblings with the start preceding the end. With the singleton model, the source conref element must be the same type as the start target. > 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. It seemed to me that this assertion came from the architectural spec 1.1. Perhaps the proposal should not spell out the processing rules but simply say that all matching rules for the conref range regarding domains and class types must be derived from the existing matching rules in the spec. > > 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. > This was about XML validation, parser-based validation rather than class/domain matching. > 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? > If the toolkit already does this degree of generalization via Deb's contribution then I certainly don't understand what proposal 12012 was proposing. The basic principle should be that if the toolkit currently generalizes a regular conref, then a similar degree of generalization would be desirable on ranged conref. > 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 Rob, I'll fix those. > 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]