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: RE: [dita] Implications of type= attribute for xref element


> -----Original Message-----
> From: W. Eliot Kimber [mailto:ekimber@innodata-isogen.com] 
> Sent: Wednesday, 2007 January 03 10:05
> To: dita@lists.oasis-open.org
> Subject: Re: [dita] Implications of type= attribute for xref element
> Michael Priestley wrote:
> > It seems reasonable though to say that when the type is unspecified
> > should be determined by inspecting the target if possible, and only 
> > default to topic if the target cannot be inspected for some reason.

I'm fine with what Michael wrote above.  It is more or less what we do
I do think that the DITA standard isn't completely clear about what is 
expected in this case. If Michael's clarification were written into the 
DITA 1.1 Standard, that would make it clearer to everyone.

I think Eliot's response is confusing and in a couple of places 
incorrect (though maybe I've misunderstood him).  More below.

> If we say "topic" is the default for xrefs to non-DITA-based content 
> (i.e., format="pdf" or format="html" or whatever) then that implies
> that xref is only intended to create references to topics or topic 
> components and not, for example, links to non-topic-ish content (for
> example, a link to an arbitrary Web site).

No, the user could explicitly set a type value other than topic in 
these cases.  They could do it on the reference element or they could 
do it on a container element and allow the reference element inherit 
a default other than topic from an ancestor.

> I think this is fine but we need to be clear that this is the 
> case and ensure that there is a different linking construct
> for handling references to non-topic-ish stuff. However, I don't
> see anything like that in the language reference (I'm looking 
> at the spec dated 2005-05-09).

I don't see a need for a new construct.

> That is, normally I would expect to have something like "link" or 
> "weblink" or "urlref" or something that is intended to point 
> to things outside the scope of my documentation set and that
> therefore are not really candidates for cross referencing, 
> where I would expect, for example, to be able to generate the
> target's title or label and page number (for paginated output).

I think this is confusing type and format.  Type tells us which 
info type something is (concept, task, reference, figure, table, 
li, ...).  Format tells us what kind of thing something is (dita, 
ditamap, xml, html, ...).  I guess that xref could be an info type, 
but it seems too generic.  The language spec allows the values for 
the type attribute to be open ended, so xref could be used, but there 
may not be processing associated with it in all cases.

Separately, I've wondered if there shouldn't be a legal format value 
of "xref" or "url" or some such that could be used with and might 
even be the default for scope="external" references.

> But if xref is intended to be a more general linking element, 
> where only one use is what I would think of as a normal xref,
> then I think that type="topic" would not be appropriate, since
> normally the stuff you *can't* resolve would not be topics
> (because normally you'd be able to resolve references to topics
> [because you have to at least know the topic's ID in order to
> author the link in the first place, 

Not true.  The topic ID is optional on the reference value unless 
you are referencing something other than the 1st topic in a ditabase.

> which means you probably have direct access to the topic or to
> some sort of database of information about the topic, for example,
> a table of topic titles and topic IDs, which is as good as resolving
> to the topic itself for the purpose of processing xrefs]).
> So I'm coming to the conclusion that the semantics of xref need
> to be clarified 

I agree with that.  I suspect that a clarification for the link 
element is also required.

> and, if that clarification includes broadening their use to be 
> more of a generic linking element, then I think that an 
> implied value of "topic" should be changed to "unknown" or be
> based on the format= value (i.e., if format="dita" then topic
> is a reasonable default, if it is "ditamap" then "map" is a
> reasonable default, if format is any other value, then "unknown"
> is a more reasonable default).

I don't agree.  Do you want different output processing for 
type="unknown" and type="topic"?  If the type isn't topic and 
the actual type of the referenced item isn't available from the 
item, shouldn't the user specify the info type?  And if they don't 
specify a type, isn't "topic" as good an info type as anything?


> Cheers,
> Eliot
> -- 
> W. Eliot Kimber
> Professional Services
> Innodata Isogen
> 9390 Research Blvd, #410
> Austin, TX 78759
> (214) 954-5198
> ekimber@innodata-isogen.com
> www.innodata-isogen.com

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