Key resolution, key text, and local fallback

[Kristen James Eberlein <kris@eberleinconsulting.com>]

This comes out of Chris Nitchie's review of the stage three proposal for 
adding multimedia elements to the base.

Originally, the <audio> and <video> topics contained the following text 
in the description of the @keyref attribute. (I judged that the content 
should be handled in the architectural topics, not the element reference.):

"When specified and the key is resolvable, the key-provided URI is used. 
If the key referenced by @keyref cannot be resolved, and href is 
specified, that value provided by @href is used as a fallback. If the 
key referenced by @keyref has no associated resource, only link text, 
and the <audio> element does not contain a fallback element, the link 
text becomes fallback content."

Chris's review comment is as follows:

"The key resolution stuff is tricky. I'm not entirely convinced that the 
local fallback should take precedence over the key text. I think of 
<fallback> as content of last resort. When a referenced key contains 
text but no file, that's a pretty clear indication of authorial intent - 
the author wants the key text, regardless of the presence/absence of 
<fallback> on the referencing element. I agree with the draft comment 
that this is all language that should go in the arch spec, and probably 
not the language reference topic."

--
Best,
Kris

Kristen James Eberlein
Chair, OASIS DITA Technical Committee
OASIS Distinguished Contributor
Principal consultant, Eberlein Consulting LLC
www.eberleinconsulting.com
+1 919 622-1501; kriseberlein (skype)