comments on 12050 plus longdescref proposal

[Michael Priestley <mpriestl@ca.ibm.com>]

General comments:
- fine with suggested wording changes
for URIs etc. - but likely to change again when we add keyref (will also
need to see if keyref needs to be added to some of these elements where
it's missing currently)
- should we always have a local text
holder for the target title and shortdesc, as we do with xref, link, and
topicref? IE, should we treat linktext and desc as a part of the general
set of link behaviors that belong together, like scope and format? Specifically
this would affect publisher, publisherinformation, source, author, authorinformation
(lq might need a sub-element of its own, like longdescref).
- the type attribute for author is currently
restrictive  - suggest changing wording to make the three existing
values supported but not exclusive (otherwise we can't use the type attribute
in its normal sense of matching the target's specialization)

Response to question re default for
the type attribute (topic, inherited, or derived from target?): 
my take would be:
        If
not specified locally, should be derived from target; if cannot be retrieved
from target, assume target is generic (ie untyped content - equivalent
to a generic topic) - maybe not quite the same as saying the default is
topic I think, since the result is not inherited
        If
specified locally, either directly on the element or on an "ancestor"
(inheritance in maps is tricky) element in the same document, should use
local value; but should still try to retrieve from target; and if target
type is  not the same as, nor a specialization of, the local type,
issue a warning. - This lets you create constraints like "all the
targets in col3 should be reference topics (or specializations of reference
topics), and should be sorted/treated as reference topics"
        


Per discussion last week on factoring
out the longdescref attribute into a separate nested element, here's the
proposal, relative to 12050:


Both image and object retain the longdescref
attribute, but it becomes deprecated in favour of a new, nested longdescref
element, modelled after xref:

- should it allow linktext and shortdesc,
per above? if we do we'll need:
        dir
        xml:lang
        translate
- other attributes: 
        href
        keyref
        type
        scope
        format
        id
        conref
        base
        rev
        status
        outputclass
        class
(leaving off the filtering attributes
on the assumption that we shouldn't be able to filter out singleton elements
- same logic used to exclude filtering attributes from topic title)

In terms of the other referencing attributes
in object: I agree with Paul they're a mess. We have a codebase attribute
that holds part of the URI, plus classid, data, and archive attributes
that hold other parts of the URI (and archive may hold multiple URIs).
But we know everything being referenced is code, and not DITA, so we probably
don't need the full referential support we have elsewhere - or at least,
we don't yet have users telling us that they do. So I'm inclined to let
sleeping dogs lie, fix longdescref for parallelism with image, but leave
the others alone.

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