#515 Bad example of feature/@fVal
This page:
http://www.tei-c.org/release/doc/tei-p5-doc/en/html/FS.html#FSSY
has the following example:
<fs>
<!--...-->
<f
name="part_of_speech"
dcr:datcat="http://www.isocat.org/datcat/DC-1345"
fVal="common noun"
dcr:valueDatcat="http://www.isocat.org/datcat/DC-1256"/>
<!-- ... -->
</fs>
The value for @fVal is "common noun", but the datatype for @fVal is data.pointer, and the value given is clearly not a pointer. To make it valid, this should be changed to fVal="#commonNoun", and the text be amended to explain that this points at a <symbol>/@xml:id in a feature structure declaration elsewhere in the file. However, if we do that, the question arises: why is the @dcr:valueDatcat being supplied in the <f> element, presumably wherever that <f> is used, when it could be applied once in the <fDecl>?
this is one of the examples of a warning that comes up in the TEI P5 build process, but isn't classified as a definite error because the value "common noun" _could_ pointing at two files called "common" and "noun"
But the value of @fVal is a _single_ data.pointer. It's flat-out wrong.
so actually the validator script needs fixing, it it does not spot that. fancy a go?
I don't know much about the validator scripts other than the detest.xml/detest.log bit, but this seems like a bite-sized problem to get started with. Is this a generic function that validates all data.pointer values, and is failing to distinguish between those that are 1–∞ data.pointer and those which are only one?
Looks like I'll need to change prevalidator.xsl, which generates pointerattributes.xsl, so that it can tell the difference between attributes which have multiple pointers and those which have only one. In the latter case, the generated XSL needs to call this:
<xsl:template match="tei:f/@fVal">
<xsl:call-template name="checkThisLink">
<xsl:with-param name="What" select="normalize-space(.)"/>
</xsl:call-template>
</xsl:template>
instead of this:
<xsl:template match="tei:f/@fVal">
<xsl:call-template name="checklinks">
<xsl:with-param name="stuff" select="normalize-space(.)"/>
</xsl:call-template>
</xsl:template>
Other similar attributes such as g/@ref should also be affected. Just making notes because I don't have time to do it today.
I've just committed a first shot at a fix for this (rev 11544). Let us see how Mr. Jenkins feels about it.
but since you fixed the error, your improved XSL won't fire....
Mysteriously, it is firing. Nothing seems to have changed at all, in fact. Although I've changed both instances of "common noun", and changed the XSL so that the prevalidator shouldn't be treating that value as a list of pointers, and although pointerattributes.xsl now correctly includes this:
<xsl:template match="tei:f/@fVal">
<xsl:call-template name="checkThisLink">
<xsl:with-param name="What" select="normalize-space(.)"/>
</xsl:call-template>
</xsl:template>
<xsl:template match="teix:f/@fVal">
<xsl:call-template name="checkThisExampleLink">
<xsl:with-param name="What" select="normalize-space(.)"/>
</xsl:call-template>
</xsl:template>
STILL the thing is finding that phrase "common noun" where it no longer exists, and STILL it seems to be treating it as a list of pointers. I even wiped out the P5Test workspace, but I get the same result. Any idea why?
Sadly, I am unable to search the closed tickets (getting "service unavailable" and similar msgs) for the context of this modification. Let me note that this entire representation is potentially grossly redundant, because both the category and the value should be aligned with the DCR at the level of the (still to my knowledge unsupported) ISO/TEI FSD.
This was a suboptimal example introduced into the Guidelines because there was a growing need for it, coming from various places in the standardization universe. But I think I commented on its non-optimality, too, in at least one place. More to the point, yes, it can be made less redundant, but in marginal cases, there is almost a zero gain in removing the redundancy (for analogies, think back to the various rend/rendition scenarios). So, while non-optimal, this example still serves.
Wrt the datatype of fVal -- would someone[1] be able to recall the details of the ISO FSR modification of the <f> representation from 2 years ago that later on percolated to the Guidelines? It had to do with splitting the value from the info on that value's datatype and it might have allowed fVal to be a string (on the assumption that it's typed externally, in the broadly understood schema).
Notes:
[1] Someone French, to be more precise. Or someone now working in France. Either of these cool someones must be able to recall that.
OK. Let's make an exec summary of my state of knowledge:
- we tried to adapt the content model of FS to align with the specificities of LAF
- this resulted in <f> to be allowed just to contain text
- looking at the latest LAF version I see a) that <f> is specified as EMPTY, that b) an example shows a couple of non empty <f>'s :-} and c) that a @value attribute on <f> is specified.
I guess someone should liaise with Nancy (the person, not the place) and see how to sort this out...
Last edit: James Cummings 2013-04-11
I think I should withdraw my remark on the datatype of fVal getting modified as a result of the modification on ISO's side. I believe that the issue was to allow for untyped values as the content of <f> elements.
The example now reads as follows:
Last edit: James Cummings 2013-11-12
Changing to RED. Council thinks it has addressed the immediate problem.
Closed per Council Chair at meeting.