RE: FW: [dita] Groups - DITA 1.1 Issue #40 (IssueNumber40.html) uploaded

Replies inline…

________________________________________

From: Michael Priestley [mailto:mpriestl@ca.ibm.com]

Sent: Tuesday, July 26, 2005 7:01 AM

To: Paul Prescod

Cc: dita@lists.oasis-open.org

Subject: Re: FW: [dita] Groups - DITA 1.1 Issue #40 (IssueNumber40.html) uploaded

> Well, the existing attribute is called "keyref", so to some degree

> we're tied to existing terminology here.

It doesn't cost much to invent a new attribute name and deprecate one that has never been used. But I don't feel strongly about this. I'll be interested to hear what other people think.

> The approach I recommend is to allow both key-based and path-based referencing

> in conref and href, making them parallel;

I'm not sure whether you mean "both" in the sense of "both at one time" or "either". I think that it is reasonable to work with a variable-driven topic in a standalone context. Topics are supposed to have meaning in and of themselves. They are often their own context.

> When you get into the range of relative paths that might apply to the

> same target, the remapping could get quite complex.

Every relative URL resolves to a unique absolute URL.

> In addition, there is then no clue to the author whether a link is variable or not.

They are all potentially variable. ;) Those that are always variable point to files that say "PLACEHOLDER" in them. The placeholder file can actually be quite helpful in establishing appropriate context (search metadata and collaborative context) for the variable.

This would look like:

"Getting started with [PLACEHOLDER]".

> I think the alternative invites confusion. IE, if you see a path

> to another file, you expect it to be there.

I agree. It think that there should always be placeholder files there. Perhaps there should be a placeholder topic type.

> Same applies to map-based linking, and appropriate use of IDs. I think

> we could strongly encourage key-based linking, but short of actually

> removing links and xrefs entirely from the topic I think we have to

> accept that the same language (DITA) allows both strong reuse and weak

> reuse models. For me the keyref vs. href distinction is yet another

> example of an existing duality in the architecture.

Forcing tradeoffs on customers is fine when there is no reasonable alternative. For maps versus xrefs that is the case. Inline linking is important sometimes, but it also causes broken links and DITA has no magic wand to fix that problem. But in this case WE are making the design choice that forces the customer to makes tradeoffs. They can have link-valid independent topic editing OR reusability: but not both.

Ultimately, I see the lack of a fallback mechanism as a big problem. It should be possible to author a topic that has a default target for links. As an author, the choice of allowing indirection should not FORCE indirection on the map creator. It's a little bit like a defaulted attribute in XML or in a programming language. I might say: "it would be nice to give my caller control over this option." That's a very different thing from saying: "my caller cannot use this function without always providing this option." There is no reason to be so strict.

> ... We have keyref on keyword and term, for example, to allow

> association with a target topic but explicitly to allow remapping

> or removal of the reference, since the reference is inline and

> would otherwise be as dangerous to reusability as a hardcoded xref.

I still don't follow why the author of an xref can choose direct or indirect linking but the author of a keyword should not have that choice.

Paul Prescod

dita message