RE: [dita] 1.2 Issue: conkeyrefend is not going to work in the case of conref to a sequence of topics

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

I don't have much to say (at least at present) about Eliot's
comments except to say that all href attributes in DITA are
(unrestricted) URI references.

If we were (and I don't know if we should) to do something 
that limited conkeyrefend to reference using only an ID, we 
shouldn't use the href attribute to do that.

paul

> -----Original Message-----
> From: ekimber [mailto:ekimber@reallysi.com]
> Sent: Wednesday, 2009 September 23 13:24
> To: dita
> Subject: [dita] 1.2 Issue: conkeyrefend is not going to work in the
> case of conref to a sequence of topics
> 
> I was reviewing the new Adoption Committee paper on using conref start
> and
> end and, in checking that it followed the spec, realized that the
> current
> definition of conrefend doesn't entirely make sense.
> 
> In the case where the initial conref target is *not* a topic (that is,
> it is
> not conreffing an entire topic), there is no need to specify anything
> other
> than the ID of the conref end element: in this case, there is no
> situation
> in which the conref end would not be in the same topic as the conref
> start
> (because the start and end must have a common parent).
> 
> In that case, requiring the full address of the conref end is Simon
> Says
> behavior (requirement of something that isn't needed and then failing
> when
> it isn't present).
> 
> In the case where the conref start is an entire topic addressed by
key,
> the
> current rules *disallow* use of conrefend to address a sequence of
> topics
> because the rules say that the target of the key overrides any topic
> addressed by conrefend.
> 
> It seems to me that conrefend only ever needs to specify a bare ID.
The
> resolution context of the ID will always be unambiguous because it is
> determined by the ultimate target of the conref start: either an
> element
> within a topic or a topic.
> 
> It seems particularly confusing in the case of key-based conref
> (hopefully
> the common practice going forward), when the conrefend specifies a
> direct
> URI *that is then ignored* by the processor.