CDR Tickets

We discussed this a bit more and solidified the requirements.

I came up with the following proposed new optional elements for the Media document. It may be worth putting all of these in a new permission wrapper element, so they can be added as a block. We can discuss this today.

PermissionInformation (possible wrapper element)

PermissionRequested: (values = Yes, No)
DateRequested:
Response: (values = Permission Granted, Permission Denied, Awaiting Response)
ResponseDate:
PermissionExpirationDate:
SpanishTranslationPermissionRequested: (values = Yes, No)
SpanishTranslationResponse: (values = Permission Granted, Permission Denied, Awaiting Response)
Comment: (multiply occurring)
CitationLink:

We plan to use some existing elements to track other information related to permissions as follows:

Acknowledgment: We will use this element to enter any specific wording that the publisher provided and must be used with the image. Note: If we decide to enter a block of elements for the permission information, we may want to move the Acknowledgment element to this new block.
ProposedUse: We will use these elements (summary and glossary) to link to the summaries or glossary terms that we received permission to reuse the image in.
Supplementary Doc: We will attach a supplementary document with all of the detailed permission information to the Media doc for reference.

Robin:

Were you going to refine these requirements to match Thursday afternoon's discussions?

Yes, thank you for reminding me.

We decided in Thursday's status meeting to add the following elements to the PermissionInformation block:

PublisherText. This is a free-text element that will be used to capture text from the publisher that is required to accompany the image when we reuse it.
ApprovedUse. This element is similar to the current ProposedUse elements in that we will be able to link to other CDR documents. The ApprovedUse element should be multiply-occurring. We will use this to track which document(s) we have received approval to reuse the image in.

We will NOT move the Acknowledgment element as suggested above. We will also NOT use the ProposedUse element as suggested above.

I propose that this new block be added after the MediaSource block and I propose that the individual elements follow the following sequence (open for discussion, of course):

PermissionInformation (wrapper element)

PermissionRequested: (values = Yes, No)
DateRequested:
Response: (values = Permission Granted, Permission Denied, Awaiting Response)
ResponseDate:
PermissionExpirationDate:
PublisherText:
ApprovedUse: (multiply occurring)
SpanishTranslationPermissionRequested: (values = Yes, No)
SpanishTranslationResponse: (values = Permission Granted, Permission Denied, Awaiting Response)
Comment: (multiply occurring)
CitationLink:

I have installed the schema changes on DEV. I made some element name changes, to avoid names that would be generic enough to risk structural definition conflicts with other attempts to use the same name in a different way (for example, I made Response be PermissionResponse). I made some guesses about which elements were optional (and I made CitationLink multiply-occurring). If any of those guesses need to be changed, let me know. Instead of having a multiply-occurring ApprovedUse element, I made it a wrapper just like the ProposedUse block (using the same structure definition). I also made the values for the response elements NMTOKENS (that is, no spaces) so that XMetaL can present the user with a picklist. If "Pending" seems like different semantics from "Awaiting Response" we can come up with some other word that's closer. Ready for user feedback and testing.

Restored the TranslationResponse options to their original values.

Schema change has been implemented.

The media doc schema looks good to me. Please add CSS. Thank you!

Do you have a thought about which elements should be included in the templates when this block is being added?

Please include the following elements in the template:
<sequence>
<element name="PermissionRequested" type="YesNo"/>
<element name="PermissionRequestDate" type="date" minOccurs="0"/>
<element name="PermissionResponse" type="PermissionResponse" minOccurs="0"/>
<element name="PermissionResponseDate" type="date" minOccurs="0"/>
<element name="PermissionExpirationDate" type="date" minOccurs="0"/>
<element name="PublisherPermissionText" type="string" minOccurs="0"/>
<element name="ApprovedUse" type="ProposedUse" minOccurs="0"/>
</sequence>

The CSS isn't completely finished since I'll have to wait for the text strings to be approved first before I can do the final alignment. However, the CSS for the PermissionInformation block has been created and is ready for review on DEV.

The following files have been modified:

• Media.ctm

• Media.css

• Media_structure.css

The CSS looks good. The one suggestion I have is to add the summary link and glossary link elements as children of the Approved Use element in the template (like the proposed use elements in the template). It seems confusing to have the instruction to link to either a summary or glossary document when I think you have to add a separate summary or glossary link element to do so.

Lastly - Bob - would it be possible to move this block of elements to follow the MediaSource block rather than at the end of the document? I didn't realize their placement until I viewed them in a sample media doc.

The CSS and template rules have been updated as requested and versioned.

• R12053: Media.ctm

• R12053: Media.css

• R12053: Media_structure.css

Re-assigning to Bob to adjust the schema.

New block has been repositioned in the schema on DEV. Ready for user review.

r12065

The placement and CSS look good - thanks! However, I am getting validation errors related to these new elements on DEV. I have added a new permission block to document CDR59983 for testing.

One of the errors had to do with an extra space in the template for the Permission Request Date field - could that be removed?

The other one seems to have something to do with the Permission Requested element, but I'm not sure what it is.

Hmm... Trying to investigate, but CDR59983 isn't a Media doc. Wrong doc ID?

Sorry about that. I probably truncated it by one digit. I don't have access to the CDR at the moment but the media doc title is "cryosurgery".

Looks like you left out the element recording whether permission has been requested for the Spanish version. Can't test because you've got the document locked.

I know I am weighing in late on this issue, and I haven't gone back and reread the issue, so I apologize if I confuse things. I added the Permissions block to the media document for colonoscopy (415504). It is confusing to me why the element for Spanish permission requested is not inserted when all the other elements are inserted, and why does it get inserted after the Approved Use block? Also, I think the instructions in the element may be wrong because they say "Optionally enter approved use".

I went ahead and validated/saved the document and it told me I had 4 validation errors but it successfully saved. I am afraid someone else will have to take a look at this--it's just been too long since I modified a document in the CDR!

Margaret,
I wanted to take a look at the document - CDR0000415504 but it remains checked out to you.
The cryosurgery document is also checked out to Robin.

Thanks - I had forgotten about the Spanish elements. I just added the Spanish Permission Requested element to cryosurgery and confirmed that it passed validation. However, since that is a required element, then I agree it should be added to the template. The instructions should read "Select Yes/No value (required)". Also, it may be just me, but I think the short name should read "Spn Perm Req" (rather than ES Perm Req). I noticed that the other Spanish element (Spanish Translation Permission Response) does not have CSS.

Margaret, I had suggested grouping the two Spanish elements at the bottom of the block (after Approved Use) to set them apart a bit but I think they could also fit nicely just before Approved Use (since we will likely use that for both Eng & Spn approved uses).

William: I checked colonoscopy back in! Sorry about that. Robin: It is fine with me to put the Spanish elements at the end. I didn't realize there were two of them, so it seemed odd to have that one element stuck in there. Also, it seems like they should be added to the document at the same time that all the other elements are when you select the Permission Information block from the elements list. don't you?

Not sure why my comment is all struck out!

Unfortunately, JIRA silently hijacks some of your punctuation for its own purposes. In this, case you have a hyphen in front of a word, which it decided meant "use strikethrough for all the following text until the next hyphen at the end of a word." You should be able to edit the comment to remove or move the hyphens. Try putting spaces around the hyphens, and/or doubling them to make them dashes.

Volker: could you modify the template to include all the required elements?

Colonoscopy is valid now. There were extra white spaces in 4 of the fields. It validated after I removed the white spaces.

The Spanish elements have been added to the Permissions template rule and the CSS for the one element that was missing has been added as well.
Please have a look on DEV.

I checked and the CSS looks good. However, the white spaces issue came up again when I used the shortcut (ALT + D) to enter the date values. When I used the date macro, it did not produce any errors. ALT + D produced errors for all the date fields. The white spaces were placed after the date values. I checked other date fields in protocols and this problem doesn't happen with the use of ALT + D to enter date values.

There was an extra line break in the template that resulted in these extra spaces. I removed the line breaks.
Please take a look again on DEV.

It worked this time without any problems. Thanks!

I added the entire block to the sigmoidoscopy media doc. All the elements properly got entered and I populated all of them. I used the date macro in the menu bar to add the date to 3 fields. When I validated and saved it gave me 2 validation errors. I don't know how to look for the white space. William could you take a look?

Looks like you entered free text for the response fields instead of picking from the valid values list. Volker: don't we usually have the placeholder use language telling the user to pick one of the valid values instead of telling them to enter a value for such elements?

It validated after I selected one of the responses from the pick list.

Hmm. Sorry about that. I thought I followed all of the instructions for selecting the fields that needed to be selected. Which fields were entered inappropriately?

PermissionResponse and SpanishTranslationPermissionResponse

Then the instructions for those 2 elements need to say "Optionally select..." instead of "Optionally enter..".

Volker: don't we usually have the placeholder use language telling the user to pick one of the valid values instead of telling them to enter a value for such elements?

Of course and once we know that an element is using a LOV we do use that language. However, it wasn't clear from the name of the elements that these 'Response' fields would use an LOV.

The template has been updated on DEV.

Yay! I added the block to bronchoscopy, entered all elements, and successfully saved and validated the record with no errors. William, not sure if you want to do any more testing, but in my opinion, this is ready to move to Closed.

I agree that it can be closed. I just tested another document and it validated without a problem and the instructions are correctly entered.

Thank you for finishing this one up! I think we should keep it open with a QA verified status for now though until we confirm that everything is working properly in production.

I think it is a terminology thing. I meant move it to the Closed column in the sprint along with all of the others that have been qa verified so it can go in the release.

Saving the latest updates in subversion:

• R12093: Media.ctm

• R12093: Media.css

• R12093: Media_structure.css

Verified on QA.

Verified these schema changes in production.