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: FW: [dita] Groups - DITA 1.1 Issue #40 (IssueNumber40.html) uploaded

Issue: "The keyref attribute is intended to provide a key-based
referencing scheme, with a level of indirection to allow for remapping
of targets when content is reused in contexts where the target is
unavailable, or a new target needs to be substituted, or several targets
need to be collapsed into one."


1. I would propose we consider calling this feature "variables" or "map
variables" to use terminology more familiar to DITA's target users.
After reading the proposal I had an epiphany that the goal is to allow
references to "vary" depending on their map context.

2. According to the proposal (Use Case step 2), authors can use keys in
hrefs. How is this different than using them in keyrefs? Perhaps you
were thinking of implementing my next point.

3. What if we simply allowed the map to remap any path at any time?
Instead of explicitly linking to a key named "copyright", you would just
link to "copyright.xml" (using standard href/conref, not keyref). Then
the map could either leave that link alone or remap it: 
 <remap original="copyright.xml" target="new_copyright.xml"/>

This would require less planning up-front. Is that a good thing or a bad
thing? I'm leery of schemes that require you to get the information
architecture all right at the beginning. What happens when you have to
deliver a document on a deadline and you find that about half of the
topics have not been carefully marked up with the appropriate keys? What
happens when you only need to do the remapping after an unforeseen
corporate merger?

You seem to have considered this "saves a step for the information
architect" but I don't think you go far enough. The whole keyref
attribute could just be removed and the mechanism could be triggered by
the map rather than the topic content.

4 What happens if the topic is viewed, printed or otherwise worked with
outside of a map context? Links simply do not resolve? Or is there a
fallback mechanism? Note that my proposal 3 has an implicit fallback
mechanism: simply use the URL that is embedded in the document.

5. Can you give an example of an element where keyref makes sense but
href doesn't?

6. I think it is worth deferring the element-level remapping until
somebody presents a strong requirement for it.

-----Original Message-----
From: mpriestl@ca.ibm.com [mailto:mpriestl@ca.ibm.com] 
Sent: Monday, July 25, 2005 4:53 PM
To: dita@lists.oasis-open.org
Subject: [dita] Groups - DITA 1.1 Issue #40 (IssueNumber40.html)

The document named DITA 1.1 Issue #40 (IssueNumber40.html) has been
submitted by Michael Priestley to the OASIS Darwin Information Typing
Architecture (DITA) TC document repository.

Document Description:
Keyref architecture for redirectable referencing (linking and reuse).

View Document Details:

Download Document:  

PLEASE NOTE:  If the above links do not work for you, your email
may be breaking the link into two pieces.  You may be able to copy and
the entire link address into the address field of your web browser.

-OASIS Open Administration

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