Re: [dita] comments on 12050 plus longdescref proposal

[Robert D Anderson <robander@us.ibm.com>]

Paul (probably working with Jeff?) - that was a great write up. I only have
a couple of general comments on top of what Michael said:

You've got the comment that "The topicref element has yet a different
definition for href (even though most of its specializations use either the
standard definition or Alternative href definition #1)." I think the
suggested updates for topicref/@href are appropriate - and should also be
applied to those specializations, except where called out elsewhere in this
document. For example, the TOC element and other lists have a different
definition that would not be impacted.

For authorinformation, the type attribute value should match that specified
on author (given that authorinformation is a specialization of author).

For Michael's longdescref suggestions - I would think that we do not need
linktext and shortdesc. The purpose of the element is to provide a link
that is used on or around an image, and is not visible except to screen
readers. In XHTML (currently the only format I'm aware of that can support
this) takes the reference as an attribute on the image; there is not link
text or any hover help. Of course current tools should not limit our plans,
but I would think that having the element would be an overall negative
right now. There is potential for the future - if XHTML changes or if other
formats can do something fancy with it - but for now we deal with user
confusion when their specified link text and hover help never get used.

For the filtering attributes - I think it would probably be silly to use
them, but for completeness they should be present. The longdescref element
would not be required, so it will not cause any problems if one is filtered
out (unlike topic titles).

Otherwise, the suggestions sound fine.

Thanks -

Robert D Anderson
IBM Authoring Tools Development
Chief Architect, DITA Open Toolkit
(507) 253-8787, T/L 553-8787 (Good Monday & Thursday)


                                                                           
             Michael Priestley                                             
             <mpriestl@ca.ibm.                                             
             com>                                                       To 
                                       dita@lists.oasis-open.org           
             07/09/2007 11:29                                           cc 
             PM                                                            
                                                                   Subject 
                                       [dita] comments on 12050 plus       
                                       longdescref proposal                
                                                                           
                                                                           
                                                                           
                                                                           
                                                                           
                                                                           





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