Sent from my Honor Mobile
-------- Original Message --------
Subject: Re: Mail delivery failed: returning message to sender
From: Laurent Romary
To: Lou Burnard
CC:
Hi Lou,
I will look at this. Could you pass around the information that I have not been a member of Loria since 2006 and that my stable employer is Inria, hence the address….
THanls.
Laurent
Le 22 mai 2016 à 16:47, Lou Burnard mailto:lou.burnard@retired.ox.ac.uk> a écrit :
Sent from my Honor Mobile
-------- Original Message --------
Subject: Mail delivery failed: returning message to sender
From: Mail Delivery System
To: Lou Burnard
CC:
This message was created automatically by mail delivery software.
A message that you sent could not be delivered to one or more of its
recipients. This is a permanent error. The following address(es) failed:
Laurent.Romary@loria.frmailto:Laurent.Romary@loria.fr
SMTP error from remote mail server after RCPT TO:mailto:Laurent.Romary@loria.fr>:
host mail2-smtp-roc.national.inria.frhttp://mail2-smtp-roc.national.inria.fr/ [192.134.164.81]:
550 #5.1.0 Address rejected.
------ This is a copy of the message, including all the headers. ------
------ The body of the message is 10371 characters long; only the first
------ 8192 or so are included here.
Return-path: mailto:lou.burnard@retired.ox.ac.uk>
Received: from hub03.nexus.ox.ac.ukhttp://hub03.nexus.ox.ac.uk/ ([163.1.154.216] helo=HUB03.ad.oak.ox.ac.ukhttp://ad.oak.ox.ac.uk/)
by relay15.mail.ox.ac.ukhttp://relay15.mail.ox.ac.uk/ with esmtp (Exim 4.80)
(envelope-from mailto:lou.burnard@retired.ox.ac.uk>)
id 1b4Uel-0002zw-mO; Sun, 22 May 2016 15:47:03 +0100
Received: from MBX01.ad.oak.ox.ac.ukhttp://ad.oak.ox.ac.uk/ ([169.254.1.225]) by
HUB03.ad.oak.ox.ac.ukhttp://ad.oak.ox.ac.uk/ ([163.1.154.216]) with mapi id 14.03.0248.002; Sun, 22
May 2016 15:47:02 +0100
From: Lou Burnard mailto:lou.burnard@retired.ox.ac.uk>
To: "tei-council@lists.tei-c.orgmailto:tei-council@lists.tei-c.org" mailto:tei-council@lists.tei-c.org>,
"s.bauman@neu.edumailto:s.bauman@neu.edu" mailto:s.bauman@neu.edu>
CC: Piotr Banski mailto:bansp@o2.pl>, Laurent Romary mailto:Laurent.Romary@loria.fr>
Subject: Re: [tei-council] content of <f> in testbasic
Thread-Topic: [tei-council] content of <f> in testbasic
Thread-Index: AQHRs66KXBdRDhMUjE+Nr79odukgv5/D9y4AgAETDkQ=
Date: Sun, 22 May 2016 14:47:02 +0000
Message-ID: <762A68C71238E2469EBDCDF70ADB249460E84DE3@MBX01.ad.oak.ox.ac.ukmailto:762A68C71238E2469EBDCDF70ADB249460E84DE3@mbx01.ad.oak.ox.ac.uk>
References: <900185842.2.1463685216080.JavaMail.jenkins@teijenkins1204>
<50368006.3.1463866357697.JavaMail.jenkins@teijenkins1204>
<22336.56913.720640.827100@paramedic.wwp.neu.edumailto:22336.56913.720640.827100@paramedic.wwp.neu.edu>,<5740EDBA.1090500@uvic.camailto:5740EDBA.1090500@uvic.ca>
In-Reply-To: <5740EDBA.1090500@uvic.camailto:5740EDBA.1090500@uvic.ca>
Accept-Language: en-GB, en-US
Content-Language: en-GB
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
Content-Type: multipart/alternative;
boundary="_000_762A68C71238E2469EBDCDF70ADB249460E84DE3MBX01adoakoxacu_"
MIME-Version: 1.0
--_000_762A68C71238E2469EBDCDF70ADB249460E84DE3MBX01adoakoxacu_
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
The key phrase here is "schematron tests we care about" of course. As noted=
earlirr on this thread it's not clear that XML validation of any kind is r=
eally useful in this case since proper validation entails something more co=
mplicated using the fsd. The fact that our processes depend on the presence=
of some arbitrary word in a message seems a bit lame however.
Sent from my Honor Mobile
-------- Original Message --------
Subject: Re: [tei-council] content of in testbasic
From: Martin Holmes
To: s.bauman@neu.edumailto:s.bauman@neu.edu,tei-council@lists.tei-c.orgmailto:tei-council@lists.tei-c.org
CC: Piotr Banski ,Laurent Romary
I have always assumed that tests intended to fail should be in detest,
not in the other tests. But to be honest I think the whole set of tests
was assembled in a piecemeal manner without much of a guiding plan, so I
wouldn't be surprised to discover that there are intentional
invalidities elsewhere.
But in this particular case, I see the problem. If you look at the
parsed log of the last successful build
(http://teijenkins.hcmc.uvic.ca/job/TEIP5-Test-dev/2848/parsed_console/),
you'll see this:
validateschematron:
[echo] Validate using Schematron
[xslt] Processing
/var/lib/jenkins/jobs/TEIP5-Test-dev/workspace/P5/Test/testbasic.xml to
/dev/null
[xslt] Loading stylesheet
/var/lib/jenkins/jobs/TEIP5-Test-dev/workspace/P5/Test/testbasic.xsl
[xslt] A feature value cannot contain both text and element
content (tei:* and text()[normalize-space(.) ne ''])
[xslt] A feature value can contain only one child element
(count(tei:*) gt 1)
In other words, these tests DO fail the Schematron check; but because
the Schematron error message does not contain the trigger word ERROR,
the build is not marked as having failed. In other words, the wrong test
is being done in the wrong place the the results are being ignored.
Two takeaways from this:
1. All Schematron rules we care about should have "ERROR" in their error
messages, otherwise Jenkins is not going to notice them. If that's
deemed too scary for end users, we need to find another trigger string
that's not so bad, and then configure the Jenkins log parser to pay
attention to it.
2. We need to go through all the tests and make sure they're actually
working properly. There could be many more examples of this.
Cheers,
Martin
On 2016-05-21 03:16 PM, Syd Bauman wrote:
The Jenkins build of P5 is failing because of the following test in
.../P5/Test/testbasic.xml:
http://www.tei-c.org/ns/1.0">
A feature may have untyped content</f>
<string>or typed</string>
</f>
<string>multiple types</string>
</f>
mixed content
</f>
</fLib>
I think these are tests that are *supposed* to fail, and thus should
be in the detest/ suite, not here in testbasic.xml.
1) Can someone (Martin?) affirm for me that testbasic.xml is
supposed to be valid?
2) Can someone (Laurent?, Lou?, Piotr?) affirm for me that an <f> is
supposed to have at most 1 child element (from class
model.featureVal, i.e. one of <fs>, <vColl>, <vMerge>, <vNot>,
<binary>, <default>, <numeric>, <string>, <symbol>, <vAlt>, or
<vLabel>)?
If I've got this right, I'll just move these tests out of testbasic,
and we'll be up and running again.
--
tei-council mailing list
tei-council@lists.tei-c.orgmailto:tei-council@lists.tei-c.org
http://lists.lists.tei-c.org/mailman/listinfo/tei-council
PLEASE NOTE: postings to this list are publicly archived
--_000_762A68C71238E2469EBDCDF70ADB249460E84DE3MBX01adoakoxacu_
Content-Type: text/html; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
<html>
<head>
<!-- converted from text --><style><!-- .EmailQuote { margin-left: 1pt; pad=
ding-left: 4pt; border-left: #800000 2px solid; } --></style>
</head>
<body>
<div>The key phrase here is "schematron tests we care about" of c=
ourse. As noted earlirr on this thread it's not clear that XML validation o=
f any kind is really useful in this case since proper validation entails so=
mething more complicated using the fsd. The
fact that our processes depend on the presence of some arbitrary word in a=
message seems a bit lame however.
<br>
<br>
Sent from my Honor Mobile<br>
<br>
-------- Original Message --------<br>
Subject: Re: [tei-council] content of in testbasic<br>
From: Martin Holmes <br>
To: s.bauman@neu.edumailto:s.bauman@neu.edu,tei-council@lists.tei-c.orgmailto:tei-council@lists.tei-c.org<br>
CC: Piotr Banski ,Laurent Romary <br>
<br>
</div>
I have always assumed that tests intended to fail =
should be in detest,
<br>
not in the other tests. But to be honest I think the whole set of tests
was assembled in a piecemeal manner without much of a guiding plan, so I
wouldn't be surprised to discover that there are intentional <br>
invalidities elsewhere.<br>
<br>
But in this particular case, I see the problem. If you look at the <br>
parsed log of the last successful build <br>
(<http://teijenkins.hcmc.uvic.ca/job/TEIP5-Test-dev/2848/pars=
ed_console/">http://teijenkins.hcmc.uvic.ca/job/TEIP5-Test-dev/2848/parsed_=
console/</a>>),
<br>
you'll see this:<br>
<br>
<br>
validateschematron:<br>
[echo] Validate using Schematron<br>
[xslt] Processing <br>
/var/lib/jenkins/jobs/TEIP5-Test-dev/workspace/P5/Test/testbasic.xml to
/dev/null<br>
[xslt] Loading stylesheet <br>
/var/lib/jenkins/jobs/TEIP5-Test-dev/workspace/P5/Test/testbasic.xsl<br>
[xslt] A feature value cannot contain both t=
ext and element <br>
content (tei:* and text()[normalize-space(.) ne ''])<br>
[xslt] A feature value can contain only one =
child element <br>
(count(tei:*) gt 1)<br>
<br>
In other words, these tests DO fail the Schematron check; but because <br>
the Schematron error message does not contain the trigger word ERROR, <br>
the build is not marked as having failed. In other words, the wrong test
is being done in the wrong place the the results are being ignored.<br>
<br>
Two takeaways from this:<br>
<br>
1. All Schematron rules we care about should have "ERROR" in thei=
r error <br>
messages, otherwise Jenkins is not going to notice them. If that's <br>
deemed too scary for end users, we need to find another trigger string <br>
that's not so bad, and then configure the Jenkins log parser to pay <br>
attention to it.<br>
<br>
2. We need to go through all the tests and make sure they're actually <br>
working properly. There could be many more examples of this.<br>
<br>
Cheers,<br>
Martin<br>
<br>
On 2016-05-21 03:16 PM, Syd Bauman wrote:<br>
> The Jenkins build of P5 is failing because of the following test in
> .../P5/Test/testbasic.xml:<br>
><br>
> <fLib xmlns=
=3D"http://www.tei-c.org/ns/1.0">http://www.tei-c.org/ns/1.=
0</a>"><br>
> <=
f name=3D"xxx">A feature may have untyped content</f>
> <=
f name=3D"yyy"><br>
>  =
; <string>or typed</string><br>
> <=
/f><br>
> <=
f name=3D"no
Laurent Romary
Inria, team Alpage
laurent.romary@inria.frmailto:laurent.romary@inria.fr