RE: [dita] comments on 12050 plus longdescref proposal

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

> -----Original Message-----
> From: Michael Priestley [mailto:mpriestl@ca.ibm.com] 
> Sent: Monday, 2007 July 09 23:30
> To: dita@lists.oasis-open.org
> 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) 

OK, but I won't make any changes based on this at this time.

> - 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). 

We decided not to do anything here.

> - 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) 

That is, for author, make the type attribute's dtd/schema
entry cdata and make the description the "standard" one
plus a mention of creator and contributor.

I'll modify 12050 accordingly.

> 
> 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" 

I need to think about this, but assuming we have agreement,
I'll modify 12050 accordingly.

> 
> 
> 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: 

Michael will write up the longdescref element as 12050a.

> 
> - should it allow linktext and shortdesc, per above? if we do 
> we'll need: 
>         dir 
>         xml:lang 
>         translate 

We decided no.

> - other attributes: 
>         href 
>         keyref 
>         type 
>         scope 
>         format 
>         id 
>         conref 
>         base 
>         rev 
>         status 
>         outputclass 
>         class 

These are as they stand in 12050 (except don't add longdesc*).

> (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. 

OK, I'll update 12050 to cause object's longdescref treatment
to parallel that for the image element.

paul