[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: RE: [dita] Question about include element and existing specializations
For me -- 100% all in favor of simplifying the key text resolution rules, even if I expect that it may end up a little bit more complex than hoped.
The one thing most likely to complicate things is that quite a lot of people today seem to use a lot of nesting to create <keyword> for their variable text. I'm not sure if this should still be allowed, or if this should be migrated to keytext:
<keydef keys="example">
<topicmeta>
<keywords>
<keyword>Reusable text</keyword>
</keywords>
</topicmeta>
</keydef>
I've also seen that where <keywords> is further nested inside of <metadata>, a legacy of early DITA versions that required the extra container.
There's no doubt that using <keytext> would be simpler, but the migration might be complicated by cases that really do want to retain the keyword. I suppose that could be another case like you raised on the call, where the safest migration could just create two copies and leave any cleanup for later:
<keydef keys="example">
<topicmeta>
<keytext>Reusable text</keytext>
<keywords>
<keyword>Reusable text</keyword>
</keywords>
</topicmeta>
</keydef>
Robert D. Anderson DITA-OT lead and Co-editor DITA 1.3 specification Marketing Services Center |
E-mail: robander@us.ibm.com 11501 BURNET RD,, TX, 78758-3400, AUSTIN, USA |
I assumed it was oversight for coderef, because it's more or less required there for some cases.
For svgref / mathmlref I think I'd prefer to add it and stay in sync with the base. It's not going to hurt anything and there's no requirement to use it, but it could be useful in cases where you're doing something odd, just as with any reference to an XML file from the base <include> element.
For <fallback> -- I think it probably makes sense to add it, unless someone has an objection.
Robert D. Anderson DITA-OT lead and Co-editor DITA 1.3 specification Marketing Services Center |
E-mail: robander@us.ibm.com 11501 BURNET RD,, TX, 78758-3400, AUSTIN, USA |
Proposal #8 to add the <include> element also covered an update to coderef, svgref, and mathmlref so that they are based on <include>.
I've been working on integrating that change into the technical content specification this evening and ran into a question.
The proposal mentioned adding @parse to those three (with default values), but overlooked adding the other new attribute @encoding from the new base element. This pretty clearly seems to be an oversight (no reason to exclude it), so I've put that onto the three existing elements.
One question I'm wondering about -- with these three currently-empty elements now based on <include>, they could also allow the nested <fallback> element for cases where backup behavior is needed.
Should that element be added as a child to those three, or should they be left as they are today? I'm not sure if this was an oversight in the proposal, or was explicitly left out.
Thanks,
Robert D. Anderson DITA-OT lead and Co-editor DITA 1.3 specification Marketing Services Center |
E-mail: robander@us.ibm.com 11501 BURNET RD,, TX, 78758-3400, AUSTIN, USA |
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]