#441 fDecl doesn't allow att.datcat yet

[Menzo Windhouwer]

TEI P5 2.1.0 says at the end of section 18.3

"Whether at the level of feature-system declarations, feature- and feature-value libraries, or individual features, it is possible to align both feature names and their values with standardized external data category repositories such as ISOcat."

However, a feature declaration can not be associated with an ISOcat data category using @dcr:datcat yet, i.e., <fDecl> [1] doesn't yet include the att.datcat [2] attribute set which <f> [3] already does.

If <fDecl> would allow @dcr:datcat it becomes possible to declare all relationships with ISOcat data categories in a feature system declaration instead of doing so highly redundant in each feature instantiation.

[1] http://www.tei-c.org/release/doc/tei-p5-doc/en/html/ref-fDecl.html
[2] http://www.tei-c.org/release/doc/tei-p5-doc/en/html/ref-att.datcat.html
[3] http://www.tei-c.org/release/doc/tei-p5-doc/en/html/ref-f.html

[Piotr Banski]

I'm happy to see this done so swiftly. Thank you, Laurent, for pushing this issue ahead and thank you, Menzo, for the implementation on the DCR side.
And may I say that when this goes through, it will be practically immediately usable in the KorAP project, where we use FSR for annotations and our FSDs are being created right this month.

[Lou Burnard]

So what, concretely, is the proposal for change to the TEI here? Reviewing the discussion, Piotr's original objection to my hasty solution of adding <fsd> to the att.datcat class seems correct. The preferred solution should be to add dcr:targetDatCat to <fsd>

We could do any of the following:

(a) Nothing. Adding attributes from another namespace is always possible and does not perturb the schema. If we choose this option however, we really must make the possibility explicit in the text of the Guidelines, and supply an example.

(b) Modify the att.datcat class soi that it also provides dcr:targetDatCat, possibly adding schematron rules to say that you can only inherit it if you are an <fsd> in which case you cannot inherit the other att.datcat attributes. This seems a bit tortuous.

(c) Explicitly add the attribute to <fsd>

(d) Define a new class att.refDatCat to supply the attribute and add <fsd> to it.

If it's not obvious I would recommend either (a) or (c).

[Laurent Romary]

I would say d), because it could also be useful for elementSpec

[Menzo Windhouwer]

You wouldn't put only <fsd> to the class att.refDatCat isn't it? Values appearing in the FSD, e.g, <tei:symbol> (see the example some posts earlier), should also use @dcr:targetDatcat or @dcr:targetValueDatcat instead of @dcr:datcat or @dcr:valueDatcat. Or did I understand the whole argument wrong?

[Lou Burnard]

On 06/09/13 11:40, Menzo Windhouwer wrote:

You wouldn't put only to the class att.refDatCat isn't it? Values
appearing in the FSD, e.g, (see the example some posts earlier),
should also use @dcr:targetDatcat or @dcr:targetValueDatcat instead of
@dcr:datcat or @dcr:valueDatcat. Or did I understand the whole
argument wrong?

(Menzo : if you meant to say "You wouldn't put only <fsd>..."
remember you have to escape the pointy brackets !)

This is a good argument for my suggestion (d) then, and since I see
Laurent also prefers that, I guess that's the right choice.

So we need (a) someone to draft the new class declaration (b) someone
to specify the elements which should be members of that class (c)
someone to write some appropriate text with examples for the Guidelines.

I can help with (a) and possibly (c), though I'd rather Piotr or Menzo
took a first stab at it. Is there a consensus on (b) ?

[Piotr Banski]

Your solution (d) seems the cleanest on the assumption that we want to continue mentioning selected attributes from other namespaces explicitly within the documentation.

Let's talk about point (b) in the action items. We want fsDecl, fdecl, symbol and numeric there, I guess -- what else?

(edit: I feel lost switching between straightforward datatyping and external semantics... string, binary, numeric -- do we want these? maybe at least experimentally? this is primarily a question to Menzo, I think)

[Laurent Romary]

elementSpec, equiv, valDef, attDef

[Menzo Windhouwer]

As in the FS instance @dcr:datcat or @dcr:valueDatcat is allowed on a <binary> and <string> as well, I would also allow @dcr:targetDatcat or @dcr:targetValueDatcat on them in the FSD.

[Piotr Banski]

Laurent says, "elementSpec, equiv, valDef, attDef". This is a bit a jump from the direct focus here, but I can understand the principle behind it. Except that we should probably divide this into {elementSpec, valDef, attDef} on one side, as the defining elements, and {equiv} on the other, as the referencing element that does a somewhat alternative job to the dcr:target* attributes.

SO, again, to reference Lou's item "(b) someone to specify the elements which should be members of that class":

• fsDecl, fDecl, symbol, string, binary, numeric
• elementSpec, valDef, attDef

Are we getting there?

[Menzo Windhouwer]

Hi, All,

Version 1.2 of the DC Reference schema is now available in HTML, RNG and RNC at isocat.org. This revision provides the targetDatcat and targetValueDatcat attributes (and elements).

Best,

Menzo

[Menzo Windhouwer]

Hi Piotr,

What does it mean that priority is lowered to 1? Will this feature be delayed (forever)? Is there anyway I can assist to get this implemented on the TEI side?

Best,

Menzo

[Piotr Banski]

Resetting the priority back to 5 -- for some reason, when you edit a ticket, the priority magically drops to the minimum unless you manually set it back to "5". I suspect a bug in the ticketing system. Thanks to Menzo for the catch (fortunately, I only modified some three tickets today!)