Learn how easy it is to sync an existing GitHub or Google Code repo to a SourceForge project! See Demo

Close

#441 fDecl doesn't allow att.datcat yet

GREEN
open-accepted
Piotr Banski
5(default)
2013-10-10
2012-09-20
Menzo Windhouwer
No

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

Related

Bugs: #441

Discussion

<< < 1 2 (Page 2 of 2)
  • Piotr Banski
    Piotr Banski
    2013-09-06

    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
    Lou Burnard
    2013-09-06

    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
    Laurent Romary
    2013-09-06

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

     
  • 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?

     
    Last edit: Menzo Windhouwer 2013-09-06
  • Lou Burnard
    Lou Burnard
    2013-09-06

    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
    Piotr Banski
    2013-09-06

    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)

     
    Last edit: Piotr Banski 2013-09-06
  • Laurent Romary
    Laurent Romary
    2013-09-06

    elementSpec, equiv, valDef, attDef

     
  • 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
    Piotr Banski
    2013-09-06

    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?

     
  • 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

     
  • Piotr Banski
    Piotr Banski
    2013-10-10

    • labels: TEI: Definition of Elements/Attributes/Classes --> TEI: Definition of Elements/Attributes/Classes, LingSIG
    • Priority: 5 --> 1(low)
     
  • 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

     
    Last edit: Menzo Windhouwer 2013-10-10
  • Piotr Banski
    Piotr Banski
    2013-10-10

    • Priority: 1(low) --> 5(default)
     
  • Piotr Banski
    Piotr Banski
    2013-10-10

    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!)

     
<< < 1 2 (Page 2 of 2)