OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

docbook-tc message

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


Subject: Re: [docbook-tc] The packageref attribute


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, "docbook-tc@lists.oasis-open.org" <docbook-tc@lists.oasis-open.org> 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 <ndw@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] | [List Home]