1.2 Issue: conkeyrefend is not going to work in the case of conref toa sequence of topics

[ekimber <ekimber@reallysi.com>]

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.

Cheers,

E.

----
Eliot Kimber | Senior Solutions Architect | Really Strategies, Inc.
email:  ekimber@reallysi.com <mailto:ekimber@reallysi.com>
office: 610.631.6770 | cell: 512.554.9368
2570 Boulevard of the Generals | Suite 213 | Audubon, PA 19403
www.reallysi.com <http://www.reallysi.com>  | http://blog.reallysi.com
<http://blog.reallysi.com> | www.rsuitecms.com <http://www.rsuitecms.com>