CDR Tickets

BZDATETIME::2013-01-10 17:37:11
BZCOMMENTOR::Volker Englisch
BZCOMMENT::1

Adjusted priority based on discussion at today's status meeting.

BZDATETIME::2013-01-14 13:47:38
BZCOMMENTOR::Volker Englisch
BZCOMMENT::2

It appears that there are two problems - the validation error for the licensee data that started with the Dec 22nd publishing job and the duplicated images on the mobile site - which are not directly related.

The second problem (images on mobile site) result from a data entry error as Margaret had already suggested. I ran a query for all documents that are listing elements with an "IncludedDevices" for which no element with the "ExcludedDevices" attribute exists. The assumption is that an image file that has been included specifically for the mobile device would need to be excluded somewhere else in the document. Most likely, the ExcludedDevices attribute did not get added to the Table element which contains the images to be replaced on the mobile site.
Following are the documents that should be checked to ensure images are only displayed once on mobile:
256783
256789
256790
256791
256797
256799
256800
256808
256834
256848
420913
420952
426393
453835
482337
665736

These summaries should probably be hot-fixed.

BZDATETIME::2013-01-14 14:30:19
BZCOMMENTOR::Volker Englisch
BZCOMMENT::3

I identified a third problem not related to the image and validation problem:
It appears that some users start entering a value of '0' for the column width of a table. Since we modified our filters to calculate the table width from the relative width specified in XMetaL (i.e. , 2, 3*, ...) the calculation fails if two columns with a width of '0' are specified.

I will make a change to my filter to default to a table width of '1*' if it has been specified as '0*' - which really means suppress this column. Of course, it would be best if users would not enter incorrect table widths.

BZDATETIME::2013-01-14 15:07:20
BZCOMMENTOR::Volker Englisch
BZCOMMENT::4

I've updated the following filters to fix the '0*' table column width:
CDR000157.xml - Vendor Filter: Summary - R11168
CDR271370.xml - Module: Vendor Filter Templates - R11168

BZDATETIME::2013-01-14 15:17:59
BZCOMMENTOR::William Osei-Poku
BZCOMMENT::5

(In reply to comment #2)
> Following are the documents that should be checked to ensure images are only
> displayed once on mobile:
>
> These summaries should probably be hot-fixed.

These have been checked and fixed. They can be hot-fixed.

BZDATETIME::2013-01-14 17:22:37
BZCOMMENTOR::Volker Englisch
BZCOMMENT::6

The following filter has been updated:
CDR609947.xml - Vendor Filter: Convert CG to Public Data - R11172

A template that was part of an included filter overwrote the original template. This problem was caused by the changes we implemented in order to display a warning message when the ALT attribute was missing from a Spanish MediaLink.

This has been fixed on MAHLER.

I'm going to run a test publishing job on FRANCK.

BZDATETIME::2013-01-14 17:38:37
BZCOMMENTOR::Volker Englisch
BZCOMMENT::7

(In reply to comment #5)
> These have been checked and fixed. They can be hot-fixed.

All but two summaries have been updated on m.cancer.gov. The other two failed due to a time out and have been restarted.

BZDATETIME::2013-01-15 17:24:48
BZCOMMENTOR::Volker Englisch
BZCOMMENT::8

(In reply to comment #7)
> All but two summaries have been updated on m.cancer.gov. The other two failed
> due to a time out and have been restarted.

All summaries have now been hot-fixed.

BZDATETIME::2013-01-15 17:33:05
BZCOMMENTOR::Volker Englisch
BZCOMMENT::9

(In reply to comment #6)
> I'm going to run a test publishing job on FRANCK.

The test publishing job on FRANCK ran successful. The validation errors we've seen since Christmas disappeared and the images aren't included twice anymore.

This is ready for testing on MAHLER or FRANCK.

William, you will see validation errors for the summaries we had identified if validating those against the DTD pdq.dtd instead of pdqCG.dtd when you compare the output between FRANCK and BACH.

BZDATETIME::2013-01-16 14:54:17
BZCOMMENTOR::William Osei-Poku
BZCOMMENT::10

(In reply to comment #9)
> (In reply to comment #6)

> William, you will see validation errors for the summaries we had identified if
> validating those against the DTD pdq.dtd instead of pdqCG.dtd when you compare
> the output between FRANCK and BACH.

To clarify, if I filter the problem documents on Franck against pdq.dtd, I should expect to see errors, right? But I shouldn't see any errors if I filter the same documents against pdqCG.dts?

BZDATETIME::2013-01-16 15:15:22
BZCOMMENTOR::Volker Englisch
BZCOMMENT::11

(In reply to comment #10)
> To clarify, if I filter the problem documents on Franck against pdq.dtd, I
> should expect to see errors, right? But I shouldn't see any errors if I filter
> the same documents against pdqCG.dts?

I realize I probably need to explain a little more to make clear what should happen:
a) You filter a document using the string
set:Vendor Summary Set
and the default (Cancer.gov) DTD: pdqCG.dtd
--> No error or warning message
b) Then you filter a document using the string
set:Vendor Summary Set
plus
name:Vendor Filter: Convert CG to Public Data
and use the (licensee) DTD: pdq.dtd

Since I have already installed the new filters on FRANCK you will not see any errors or warnings for either of these approaches on MAHLER or FRANCK. However, you will see a validation error for (b) on BACH.

Note: BACH and FRANCK have nearly identical data since FRANCK had just been
refreshed.

BZDATETIME::2013-01-16 17:00:53
BZCOMMENTOR::William Osei-Poku
BZCOMMENT::12

On both Bach and Franck, I get errors when validating against pdq.dtd but not when I validate again pdqCG.dtd.

BZDATETIME::2013-01-16 17:02:20
BZCOMMENTOR::Volker Englisch
BZCOMMENT::13

Could you give me the document that you've used?

BZDATETIME::2013-01-16 17:03:55
BZCOMMENTOR::William Osei-Poku
BZCOMMENT::14

(In reply to comment #13)
> Could you give me the document that you've used?

256848
256800

BZDATETIME::2013-01-16 17:11:54
BZCOMMENTOR::Volker Englisch
BZCOMMENT::15

Are you adding the second filter listed under (b) when you're validating against pdq.dtd?
If you are, could you please send me the validation messages?

BZDATETIME::2013-01-16 17:18:38
BZCOMMENTOR::William Osei-Poku
BZCOMMENT::16

(In reply to comment #15)
> Are you adding the second filter listed under (b) when you're validating
> against pdq.dtd?
> If you are, could you please send me the validation messages?

Here is the error from Franck:

A problem occurred in a Python script.

d:\cdr\Log\tmphar6ah.html contains the description of this error. d:\python\lib\cgitb.py:173: DeprecationWarning: BaseException.message has been deprecated as of Python 2.6 value = pydoc.html.repr(getattr(evalue, name))

BZDATETIME::2013-01-16 17:35:12
BZCOMMENTOR::Volker Englisch
BZCOMMENT::17

This is a Python error, not a validation error. I'm assuming you see a different output on BACH. Is that correct?

From the log file it appears that you have a namespace error but I can not reproduce it here.
Could you send me (in an email) the XML output?

BZDATETIME::2013-01-17 11:01:06
BZCOMMENTOR::William Osei-Poku
BZCOMMENT::18

I tried it all over again this morning and everything appears to be working as expected. I get no validation errors on Franck but I get them on Bach. Please promote to Bach.

BZDATETIME::2013-01-17 17:00:05
BZCOMMENTOR::Volker Englisch
BZCOMMENT::19

The following filters have been updated on BACH:
CDR000157.xml - Vendor Filter: Summary - R11168
CDR271370.xml - Module: Vendor Filter Templates - R11168
CDR609947.xml - Vendor Filter: Convert CG to Public Data - R11172

We'll have to wait until the Friday publishing job finished before we can check that everything is working properly again.
I will do that on Monday.

BZDATETIME::2013-01-22 16:01:38
BZCOMMENTOR::Volker Englisch
BZCOMMENT::20

Everything worked properly but there was a minor, unexpected change. The case of the document encoding attribute changed to upper case and this caused all summaries and protocols to be listed as updates for the licensees.

I'll have this fixed for next weeks publishing run.

BZDATETIME::2013-01-28 15:33:30
BZCOMMENTOR::Volker Englisch
BZCOMMENT::21

(In reply to comment #20)
> The case of the document encoding attribute changed to upper case

This has been reverted with the changes:
CDR306482 - Module: Global Filter Templates - R11231
CDR609947 - Vendor Filter: Convert CG to Public Data - R11231

I've checked the licensee output and everything is back to the original again.

I believe this issue can now be closed.

BZDATETIME::2013-01-30 14:20:43
BZCOMMENTOR::William Osei-Poku
BZCOMMENT::22

(In reply to comment #21)

>
> I believe this issue can now be closed.

Issue closed. Thanks!