OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

dita message

[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


I think the original intention of that statement was to ensure that the two target elements were siblings, so that you couldn’t conref to <li>s in two different lists or conref to unbalanced ranges. Michael brings up a good point though, that validation of the innards of the range must be ensured. Checking the parent element of both the source and the targets could provide this validation.

 

Another option would be to restrict all the element siblings in the range to be all of the same type e.g. all <li>s or all <step>s etc. This would prevent users from creating a conref to the following types of ranges (from x -> y):

<b id=”x”>Some bold text</b><mySpecialisedElement>Some non-bold </mySpecialisedElement> text<b id=”y”>More bold</b>

 

This is probably be too restrictive to be useful though.

 

Michael.

 

From: Michael Priestley [mailto:mpriestl@ca.ibm.com]
Sent: September 27, 2007 11:00
To: Grosso, Paul
Cc: dita@lists.oasis-open.org
Subject: RE: [dita] Groups - DITA Proposed Feature #12013 Referencing a range of elements (conrefrange.html) uploaded

 


> 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>?


One reason for it to mean that would be to avoid situations like allowing conref of a range of elements into a context where only one of them is allowed, or where the range includes elements disallowed in the referencing context. If the parent elements are the same, then the rules of what's allowed in the range are the same.

With generalization-on-the-fly, the parent element of the range could be a specialization of the parent element of the reference, but it does seem to me that you'd get an important validity guarantee by comparing the parents in the range case. Otherwise conref-with-range would open up a world of referencing invalid content that conref currently prevents. In other words, without a check on the parent element, we would be dramatically loosening the constraints on what conref allows, in just this one place.

Speaking of which, I think Yas also mentioned:

>It is already possible to include invalid content

Is this true? It's definitely not the intent of conref. I thought it was doing a pretty good job of avoiding validation errors. What case were you thinking of?

Michael Priestley
Lead IBM DITA Architect
mpriestl@ca.ibm.com
http://dita.xml.org/blog/25


"Grosso, Paul" <pgrosso@ptc.com>

09/27/2007 01:47 PM

To

<dita@lists.oasis-open.org>

cc

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]