OASIS Open Mailing List Archives  ·  All Lists  ·  docbook-tc  ·  2022-03

docbook-tc — archive

[Date Prev]  |  [Thread Prev]  |  [Thread Next]  |  [Date Next]   —  [Date Index]  |  [Thread Index]  |  [Month Index]  |  [List Home]

DocBook Technical Committee Meeting Minutes 10 NOV 2021


WIthout the id on packagesynopsis so we could do an id/idref type of link, I'm leaning toward your suggestion of optional text attribute. --Scott On 3/20/22, 9:51 AM, "[email protected]" <[email protected]> wrote: Hi folks, At the last TC meeting, we decided that I should add a packageref attribute to the elements that can be inside a packagesynopsis so that they can refer back to the synopsis even if they aren’t logically contained inside it. How should that work? 1. Make it an IDREF attribute, like linkends. That’s tempting except    that in 5.2, the elements that have linkends actually have    “common.linking.attributes” so they can use either linkend or    xlink:href. 2. Ok, do that. Well, that’s tempting except that we don’t usually do    that on block elements. It would appear to give the various synopsis    elements the semantics of “thing you can click on”; it would have not    just xlink:href but all the other xlink:* attributes as well. I    suppose we could hardcode xlink:actuate to “none”, but I’m not sure    anyone would care. 3. The only “block element with links” I can think of is annotation. For    the “annotations” and “annotates” attributes, we punted the question    and made them text attributes. That leaves the semantics up to the    processor. You don’t get any kind of link checking during validation,    but at the same time, you can have annotations in separate files and    you don’t get broken link errors. The semantics of annotation is    explicit about this, an annotation with no referents doesn’t apply;    I’m not sure that’s what we’d want for packageref. 4. Wait a minute, the packagesynopsis isn’t (necessarily) identified by    an xml:id at all! It’s identified by its <package>. It definitely    shouldn’t be a IDREF! This pushes validation even further into the    processing tools, but they’re pretty capable these days. On the weight of 3 and 4, and for simplicities sake, I think “packageref” as an optional text attribute is the best answer. Anyone want to argue for something else?                                         Be seeing you,                                           norm -- Norman Tovey-Walsh < [email protected] > https://nwalsh.com/ > The direct use of force is such a poor solution to any problem, it is > generally employed only by small children and large nations.--David > Friedman

[Date Prev]  |  [Thread Prev]  |  [Thread Next]  |  [Date Next]   —  [Date Index]  |  [Thread Index]  |  [Month Index]  |  [List Home]