The lack of <fallback> in the specializations was an oversight on my part; I was focused on backwards compatibility and hadn't thought this part through. I don't have a problem adding it to those. I also failed to add @encoding to <coderef>.
I'm not sure whether it should be added to <svgref> or <mathmlref> as, being XML-reference elements, encoding handling follows normal XML parsing rules (i.e. it should come from the <?xml?> PI in the referenced file).
Chris
From: <dita@lists.oasis-open.org> on behalf of Robert D Anderson <robander@us.ibm.com>
Date: Tuesday, December 3, 2019 at 9:10 PM
To: "DITA TC (dita@lists.oasis-open.org)" <dita@lists.oasis-open.org>
Subject: [dita] Question about include element and existing specializations
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 |
|
|
|
|
E-mail:
robander@us.ibm.com |
|
