nav[aria-label="Primary Navigation"] { padding: 0; & ul { list-style: none; width: 100%; display: flex; flex-direction: row; justify-content: start; align-items: start; gap: 30px; padding: 0; & li { margin: 0; } & ul li { list-style: none; } } }

Tagging quirks

SecretHen

Various metadata fields are saved in Tagger GUI by selecting options from a dropdown. When we go to inspect the results in the TeamSite File->Properties screen, there are discrepancies which we do not understand

In some cases the selected values are displayed as we would wish e.g.
Name Value
CS:business_unit HR
but sometimes two fields are displayed, thus
Name Value
CS:business_unit HR
CS:business_unit/HR y
We cannot work out what triggers this, but such fields seem not to be reported reliably using the iwextrattr CLT
Any thoughts ?

Hen

Find more posts tagged with

Comments

Adam Stoller

Is there some commonality between the items that add the extra definition of 'y'?

i.e. are they TeamSite/Metadata/ fields or are they perhaps other forms of TeamSite extended attributes? are they select lists rather than text fields (or vice-versa)?

I know what you're talking about with regard to these seemingly extraneous attribute key/value pairs, but I can't say I ever actually followed it up to determine a cause/effect relationship - of which I'm pretty sure there is one.

--fish
(Interwoven Senior Technical Consultant)

SecretHen

Yes - they are appear as dropdowns in Tagger GUI - this sort of thing

<item name="content_type">
<select>
<option label="Advertising Materials" value="Advertising_Materials"/>
<option label="Best Practice" value="Best_Practice"/>
<option label="Brochure" value="Brochure"/>
<option label="Case Study" value="Case_Study"/>
<option label="Discussion Thread" value="Discussion_Thread"/>
etc.
</select>
<text required="t" maxlength="60"/>
</item>

but are purely manually selected i.e. do not have any MT logic to pre-select them

Because of this I wanted to suppress the Regenerate button from Tagger GUI (see my other thread). This does disappear when the field exists in datacapture.cfg but not in metatagger.cfg
But this seems to have 2 undesirable side-effects
1. the appearace of this "y" behaviour
2. the item is no longer reported by iwextrattr

Replacing the item seems to correct 2. but not 1. !!! Once the y entries are there they do not necessarily disappear, or get updated, even when out of sync with their "parents" - although re-saving seems usually to help

Any idea if I can force MT to regenerate the config files?

Edited by SecretHen on 07/14/03 08:31 AM (server time).

Migrateduser

Manual datacapture widgets that can in principle have multiple values (like a select) use the TeamSite metadata "y" convention. For example if "Brochure" and "Case Study" were selected you would get 3 extended attributes:
name="content_type" value="Brochure, Case_Study"
name="content_type/Brochure" value="y"
name="content_type/Case_Study" value="y"
So I think it make slightly more sense if multiple values have been selected, but I agree it is a bit a bizarre when only one value has been picked. Can't you just ignore the "y" version of the metadata? All these entries should appear when you run iwextattr.

Having a regenerate button appear when that field does not exist in metatagger.cfg sounds like a bug to me.

Migrateduser

Hi

Below section shows 2 item types within an item. This is not a supported behavior defined within datacapture DTD. The resulting behavior is untested / undefined which may explain the odd results you are seeing. You must define an item to be of specific type - you can only define multiple types if and only if you use access control to switch between different item types. Please check templating developer's guide to get a sense of how to set up datacapture.cfg.

<item name="content_type">
<select>
<option label="Advertising Materials" value="Advertising_Materials"/>
<option label="Best Practice" value="Best_Practice"/>
<option label="Brochure" value="Brochure"/>
<option label="Case Study" value="Case_Study"/>
<option label="Discussion Thread" value="Discussion_Thread"/>
etc.
</select>
<text required="t" maxlength="60"/>
</item>

SecretHen

jpierre ...
"All these entries should appear when you run iwextattr."
Problem is that they do not - no "y" type metadata is included in the output

Edited by SecretHen on 07/15/03 02:43 AM (server time).

SecretHen

jcho
"Below section shows 2 item types within an item. This is not a supported behavior defined within datacapture DTD"

I do not understand - where are there 2 item types?

Edited by SecretHen on 07/15/03 02:44 AM (server time).

Adam Stoller

I believe the two item types being referred to are <select> and <text> - however, my reading of the DTD:

<!ELEMENT item (label?, description?, database?, (... | text | ... | select | ...)+)>

is that it might be legal to do that. Or that you can have multiples of a single item-type, or that perhaps text needs to come before select.

This is just reading from the DTD - I'm not sure what the underlying software actually supports - it is possible that the DTD is incorrect (if so, a bug should be filed on it).

On the chance that what is being proposed is correct - try removing the <text>...</text> piece and see if the problem remains. If so, then I'd suggest contacting Interwoven Support to see if they can reproduce and report a bug.

--fish
(Interwoven Senior Technical Consultant)

Migrateduser

When I run iwextattr they show up for me. How do you know those entries are in EAs in the first place?

SecretHen

I can see them loud and clear in TeamSite File Properties

Adam Stoller

Can you show the *exact* command line you are issuing within iwextattr and the results that get displayed?
Also perhaps take a screen-shot of the File Properties window and attach it (either as a JPG or in a word doc or something

--fish
(Interwoven Senior Technical Consultant)

cjk

As a colleague of Hen's I can supply the info.

The command to extract the extended attributes is:
/usr/iw-home/bin/iwextattr -g subjectMetadata0 filename

If there is more than one 'chunk' it is catered for.

Here is a section of the file properties
TeamSite Metadata&colon;
Name Value
CS:business_issue Business Environment
CS:business_unit
CS:company_name ANother plc
CS:industry information
CS:internal external
CS:regions Global
CS:regions/Global y
PR:business_issue
PR:business_unit
PR:company_name
PR:industry
business_issue
business_issue_codes
business_unit
business_unit_codes
contact
content_type Advertising_Materials
location
location_codes

the CS:regions does not appear in the xml for subjectMetadata0.
I take it anything that one wants to appear in said xml must have an entry in metatagger.cfg?

thanks

Migrateduser

Only metatagger suggested metadata will appear in subjectMetadata0. My guess is that CS:regions is populated through a manual capture widget defined in datacapture.cfg. Including the field in metatagger.cfg is necessary for it to get in the XML...the XML is the subset of metadata fields that MetaTagger thinks it helped to populate. The "y" attributes will not appear as an attribute in the xml...it will only appear in separate EAs.

To get all name value pairs from iwextattr you can of course just run it like this:
/usr/iw-home/bin/iwextattr -l filename

Adam Stoller

The command to extract the extended attributes is:
/usr/iw-home/bin/iwextattr -g subjectMetadata0 filename

If there is more than one 'chunk' it is catered for.

Here is a section of the file properties
TeamSite Metadata&colon;
Name Value
CS:business_issue
...

I'm not quite sure where the key and the value separate in the output you showed, but the command is probably wrong.

I think you need to use:
iwextattr -g TeamSite/Metadata/subjectMetadata0 filename

In order to extract that piece of date - i.e. the way it's displayed in the File Properties window is "nice" but not "accurate" in terms of coding for the command line.

As was pointed out - if you run: iwextattr -l filename you'll see all the key/value pairs with the key names fully spelled out.

--fish
(Interwoven Senior Technical Consultant)