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:]
Sent: September 27, 2007 11:00
To: Grosso, Paul
Cc:
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
http://dita.xml.org/blog/25
"Grosso,
Paul" <>
09/27/2007
01:47 PM
To
<>
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.
>
