Menu
▾
▴
#581 `<attRef>` needs better documentation
As pointed out during the thread starting here on TEI-L:
http://listserv.brown.edu/archives/cgi-bin/wa?A2=ind1306&L=TEI-L&F=&S=&P=86274
the <attRef> element is never mentioned in chapter 22. There are also only two examples for it, which are identical. The use-case discussed in the thread might provide possible examples.
The example given in the P5 documentation is as follows:
but I was not able to get it to work. However, this worked:
Louis-Dominique's issue has been corrected -- you have to drop the colons, and the examples now shows correctly, but that fact also has to be documented.
This is potentially a solution to the unease with which we contemplate the idea of claiming membership of a class, then deleting some of its attributes; with this, you can have an element that does not claim membership of the class, and instead pulls in only the attributes it wants from that class.
We really need to revamp the syntax, here, though. Instead of name= having a RELAX NG pattern, we really should refer to the class and particular attribute. E.g. <attRef class="att.global" name="xml:id"/>.
Last edit: Martin Holmes 2013-11-13
Action on MH to watch as SR and SB implement this, and then document it properly when it's done.
LB suggests we can use classRef instead, using include or exclude of attributes. Therefore we might be able to get rid of this element.
Posted to the Council list asking for any answers to these questions:
Are there (currently) any good use-cases for end-users which depend
on the use of
<attRef>and which will work with current ODD processing?If there are such use-cases, can the same results be achieved using
other existing elements and attributes?
Will future plans for ODD make
<attRef>obsolete anyway?No responses to the questions as of today. I guess this will need to be discussed in the FtF.
Feature request to extract attribute from locally defined element, either because it's special or because it over rides class definition, would be useful. Maybe add @element as an alternative to @class
F2F Raleigh: Prods MH to progress ticket.
A summary of what I know for the Council FtF in Ann Arbor:
The P5 Source makes absolutely no use of
<attRef>; the explanation of it in the USE chapter suggests that ODD pre-processing does make use of it, and in fact if I capture the odd.processedodd file created during ODD processing, preventing it from being deleted at the end, I do find instances of it; and it's mentioned a lot in the ODD processing modules of the Stylesheets.When I make use of it in an ODD file to (for example) add @source from att.sourced to the
<p>element, it works perfectly (which is what you'd expect; ODD processing wouldn't work otherwise).So it seems to me that we have these options:
Personally, I favour #1 or #2. I haven't seen any convincing use-cases for #3 or #4 which cannot be accomplished in other ways. The use-case for #3 might be (for instance) adding @xml:id to a new element you're creating, but that could be achieved by adding it to add.global and then deleting the other global attributes you don't want (admittedly long-winded but familiar); in the case of #4, I think that once you're sharing an attribute between two elements you might as well create a class they can both belong to which defines the attribute, rather than define it on one and refer to it from the other.
Last edit: Martin Holmes 2015-05-25
MH to go forward with option 2+3 (explain that we use it internally, but it could be used in an ODD directly), with examples. An example that makes some sense: you add a new element in your own namespace, and you want to pull @xml:id from att.global, but don't want the others. You could add it to att.global, then delete all the other consequences, but it might be simpler to use attRef.