Attribute

This Output Kind was introduced in Perfion 4.5 2019 R1, and should not be confused with outputting an attribute as a Field as described in Section Field where an attribute from a Perfion Query Result is output as a Field.

The Output Kind Attribute is used to “decorate” an already existing Output-element with an attribute.

Attribute
What can be output	Supports	Supported Entities
a Features a Attributes a Literals	a Multi value features a Localizable features r Output Kind Parameters	a Site a Category a Product a Variant
Sample Mappings
Sample output
<Response>    <Result>    <TotalCount>1</TotalCount>    <Product>       <!-- Fields from ERP and Perfion omitted here for brevity -->       <field name="NoOfCups" value="4" size="Medium" />        <field name="Volume" value="0.35" unit="L" />    </Product>    </Result> </Response>

Table 1: Summary of Output Kind Attribute.

Notice the mapping with Output Kind Attribute. In the example in Table 1 the value of the feature CupSize is mapped to an element named NoOfCups@size an attribute named size. The “@” makes sure that the data get’s mapped on an attribute on the output field and not as a separate output field.

It even works for fields originating from a *-mapping. In addition, fields having their data coming from a Literal or Attribute can be decorated.

It is not only Fields that can be output using the Attribute Output Kind. Also Image-, Attachment-, Url-, RelatedProduct- and RelatedCategory-elements can be decorated.

Combining non-localizable with localizable features on fields and attributes

It is worth looking into localizable features and combining localizable features with non-localizable features. In Table 1 we combined NoOfCups and CupSize-features that happened both to be non-localizable. Similarly combining two features that are both localizable works as expected. However, what about making a localizable feature and map it to a Field while a non-localizable is output as an Attribute on that same Field. How would that work? Let us consider the remaining 3 localization-combinations in the following example:

Example

Consider the following data on a product:

ItemName- and Color-features are localizable. While RRP (RetailPrice) and RetailPriceCurrency are not. For the sake of simplicity, assume that we have two languages in play: English and German.

Let us see how the possible combinations are handled by the ECommerce API:

Combining two localizable features
Mappings
Description	Both ItemName and Color are localizable features, so for each language the ItemName is output as a separate Field named Title for each culture. This makes it obvious that each localizable Color-value-attribute should be put on the Field matching the culture. I.e. the English Color is matched with the English Title and output here.
Result	<Product id="636" ecommerceproduct="983ST">   <Fields>     …     <Field name="Title" color="Yellow" culture="en-US">Vacuum Jug EM77 Yellow</Field>     <Field name="Title" color="Gelb" culture="de-DE">Vacuum Jug EM77 Gelb</Field>     …   </Fields> </Product>

Combining a localizable Field with a non-localizable attribute
Mappings
Description	Here the localizable ItemName still outputs a Field named Title for each language/culture. The non-localizable RetailPriceCurrency is simply added to each one.
Result	<Product id="636" ecommerceproduct="983ST">   <Fields>     …     <Field name="Title" currency="Euro" culture="en-US">Vacuum Jug EM77 Yellow</Field>     <Field name="Title" currency="Euro" culture="de-DE">Vacuum Jug EM77 Gelb</Field>     …   </Fields> </Product>

Combining a non-localizable Field with a localizable attribute
Mappings
Description	Here the non-localizable feature RetailPrice is given the localizable feature Color as attribute. Since RetailPrice is only output once, color is output only once. The ECommerce API picks the value of the primary language which is the first language specified in Settings (See Languages-setting).
Result	<Product id="636" ecommerceproduct="983ST">   <Fields>     …     <Field name="RetailPrice" color="Yellow">49.95</Field>     …   </Fields> </Product>

Table 1: 3 of the 4 different combinations of localizability of 2 features.

The last combination should be avoided, since it does not output localizable data other than that in default language (in Table 1 it is the colors in any language but English that are lost). Unfortunately, this hits the often-wanted combination of outputting some sort of measure combined with its unit. Consider this example:

<Field name="TopSpeed" unit="km/h">206</Field>

Here TopSpeed is assumed to be non-localizable and TopSpeedUnit to be localizable (since it would be “Kilometers per hour” or “km/h” in English and “Kilometers pro Stunde” or “km/s” in German). However, as we saw from Table 1, this combination gives us problems. There are multiple solutions to this:

Solution #1: Output both as Fields 

<Field name="TopSpeed">206</Field>

    <Field name="TopSpeedUnit" culture="en-US">km/h</Field>

    <Field name="TopSpeedUnit" culture="de-DE">km/s</Field>

Here the foreign system must somehow know how to connect the two.

Solution #2: Make TopSpeed localizable and give it same value in all languages 

<Field name="TopSpeed" unit="km/h" culture="en-US">206</Field>

    <Field name="TopSpeed" unit="km/s" culture="de-DE">206</Field>

This gives the result wanted, but forces users to maintain the same value for all languages.

Solution #3: Same as Solution #2 but using a self-remote to output same value in all languages

This outputs the same as Solution 2. The idea is to make a self-remote, that is a query “localizing” all features you need to pair up with their appropriate units. It is beyond the scope of this document to describe how to do a self-remote in Perfion. Consult Perfion to get help if you are in doubt.