OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.


Help: OASIS Mailing Lists Help | MarkMail Help

dita message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]

Subject: 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:
- other attributes:
(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

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]