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 <> 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
Attachment:
signature.asc
Description: PGP signature
