Validating Attribute Data Before Listing Items

Buyers and sellers expect Item Specifics and return policy options to be consistent and appropriate in listings. For example, a user does not want to see San Francisco listed as a city in New York. Sellers also want their Item Specifics to be correct so that their listings are more likely to appear in product finders search results. For example, a buyer will not find a pair of men's jeans if the seller specified a waist size that is not recognized by the search engine, and a buyer will not find a particular book by its ISBN if the seller specified the wrong number characters in the ISBN value.

eBay provides several mechanisms to help sellers specify correct values in Item Specifics and return policies. These include indications of which attributes are required, definitions of dependencies between attributes, and other validation rules.

To determine how to validate attributes for a given category, you need to refer to the attribute meta-data that you have stored locally. See Retrieving Attribute and Product Meta-Data.

Please note that some attributes that are returned from GetAttributesCSCall and GetProductSellingPageCall are not necessarily valid for listing items. The presentation instructions provide hints as to the attributes that should be presented to a user. The Item Specifics SYI XSL stylesheet uses these presentation instructions to make sure the user will only choose valid attributes. We recommend that you use the XSL stylesheet when working with Item Specifics.

This section describes additional information that you should understand in order to help sellers create listings with valid Item Specifics and return policies. It covers the following topics:

Listing in Two Categories with Item Specifics

Specifying Date Attributes when Listing Items

Specifying Units of Measure when Listing Items

Creating Listings Before the Listing Start Date

Presenting Valid Attributes and Values to Users

A Basic Validation Algorithm

Validation Rules in the Attribute Meta-Data

Listing in Two Categories with Item Specifics

The following information is only applicable when you are listing an item the standard way with Item Specifics, and the item is being listed in two categories:

If you are listing in two categories that are mapped to different full characteristic sets, the request should include two separate AttributeSet nodes to describe the Item Specifics for each category. If you are using the Item Specifics XSL to render the meta-data in a graphical user interface, you should display the full set of characteristics for PrimaryCategory and SecondaryCategory on separate pages or forms.
If you are listing in two categories that are mapped to the same full characteristic set (e.g., Men's Big & Tall Outerwear and Men's Regular Other Jackets both map to Men's Outerwear), the request can only include one AttributeSet node.
If you are listing in two categories and one of them is mapped to the Tickets characteristic set, the ticket category must be specified as the primary category (i.e., PrimaryCategory, not SecondaryCategory).

If a category is also mapped to site-wide characteristic sets, the request can include any number of additional AttributeSet nodes to describe those site-wide attributes. If you are using the Item Specifics XSL to render the meta-data in a graphical user interface, you can display any number of site-wide characteristics for PrimaryCategory and SecondaryCategory on the same page as each full characteristic set.

If you are listing with Pre-filled Item Information and the item is being listed in two categories, see Product Search Considerations when Listing in Two Categories.

Specifying Date Attributes when Listing Items

In item-listing requests (like AddItemCall), dates are either entered as a combination of attributes (for Tickets) or as free text in the ValueLiteral field:

For predefined date attributes, the choices for year, month, and day are returned in the XML in the GetAttributesCSCall response and have unique IDs within the characteristic set. In this case, in the AddItemCall request you specify separate attribute and value IDs for each portion of the date.
For other attributes, the user might be expected to enter a date (or might have the option to choose "Other" and then enter a date). In the presentation instructions for a characteristic set, dates might be formatted in a way that is appropriate for the category and site (e.g., "Jan-05-2003"). Thus, when you render the XML by using the Item Specifics SYI XSL stylesheet, the user might use a similar format (e.g., "Jan-05-2003" or "01-05-2003") when entering a date in a text field.

In the listing request, dates entered in the ValueLiteral field (rather than as separate attributes) should use one of these formats (so you might need to convert the user's input):

YYYY-MM-DD

YYYYMMDD

YYYY-MM

YYYY

The response will be in the format YYYYMMDD. If the input date was in the format YYYY-MM or YYYY, the returned value will be formatted as YYYYMM00 or YYYY0000 respectively (where "00" represents null).

Specifying Units of Measure when Listing Items

In the XML that is returned from GetAttributesCSCall and GetProductSellingPagesCall, attributes that represent units of measure include a DefaultUnitOfMeasureFormatString field. Usage of this information is optional.

The default unit of measure format string contains a hint (e.g., "{0} Mhz") that indicates how an application can display an attribute whose values should be interpreted according units of measure (e.g., Max Processor Speed), where {0} is a placeholder for the quantity and the second value (Mhz) is the default base unit.

In the Value elements, the quantity and units are scaled with respect to the default unit according to standard upper and lower bounds (e.g., 1500 Mhz is represented as 1.5 Ghz). In the characteristic set XML, the Value.Name field specifies the quantity in the default unit (e.g., 1500). The Value.DisplayName field specifies the scaled quantity and scaled unit (e.g., 1.5 Ghz).

Usage of the default format is optional. If you pass in an unscaled value for a unit of measure (e.g., "1500" for an attribute with "Mhz" as the default unit) in the ValueLiteral element in the AddItem call (and related calls), eBay converts the value to the quantity that is appropriate for the unit of measure (e.g., 1.5 Ghz).

Creating Listings Before the Listing Start Date

Many times, a seller wants to create a listing and have it be active on the eBay site as soon as the seller completes the Sell Your Item flow. That is, they want the listing start date to be "today".

Some sellers prefer to create listings in advance of the start date and then schedule the listings to become active at a later date (often called pending or scheduled listings).

The Item Specifics meta-data for a given category can change without notice. If your application supports creating scheduled listings with Item Specifics and Pre-filled Item Information, you need to make sure that any Item Specifics the user selected will be valid when the listing becomes active.

The easiest way to make sure the attributes will be valid is to use eBay's built-in listing scheduling functionality. To do this:

Specify the listing start date in the Item.ScheduleTime property.
When the user has finished specifying the listing details (with the current set of Item Specifics), submit the listing immediately. The validation of the Item Specifics occurs at this time.
When the scheduled time arrives, the listing simply becomes active, and no additional validation occurs, even if the meta-data has changed on the site.

If you prefer to store pending listings locally (without using eBay's listing scheduling functionality), you should execute GetAttributesCSCall again before submitting the listing. If the meta-data has changed since the seller originally defined the listing, make sure the listing's Item Specifics are still valid. The way you do this depends on your application's needs. For example:

You could save the version of the meta-data that was in effect at the time you created the listing, and then compare its list of attributes and values to the latest meta-data to determine whether any changes have occurred. If changes have occurred that appear to affect the listing, notify the user and display the appropriate errors in the user interface.
You could compare the attributes that were set on the Item object to the latest meta-data and make sure all attributes and values valid.

If you are using the XSL solution, one way to do this would be to generate a SelectedAttributes node (in raw XML) based on the attributes that were set on the item (or retrieve the SelectedAttributes node that were used to create the AttributeSet object originally) and validate it against the new meta-data. If the validation fails, notify the user and display the appropriate errors in the user interface. See Converting Selected Attributes to AttributeSetType for more information about the SelectedAttributes node.

Presenting Valid Attributes and Values to Users

If you are using the Item Specifics Sell Your Item (SYI) XSL stylesheet, you can skip this section, as the stylesheet will cause the Item Specifics page to render data correctly as editable or read-only. If you are using the Attributes Library, the sample AttributesMaster, ValidationRule, and VResult classes handle all the following logic for you.

If you are not using the XSL stylesheet, it is a good idea to present attributes and values as editable, read-only, required, etc. in the first place, so that the user selects valid combinations of attributes and values before submitting the data. (If you are using the Item Specifics SYI XSL stylesheet, the correct presentation behavior is handled for you.)

For example, these are some steps you might take to help the user select valid combinations of attributes and values:

Correctly present data as editable or read-only:
If EditType = 0, the user can select a value.
If EditType = 1, present the attribute as read-only. (You do not need to include it in the AddItem call)
If EditType = 2, determine whether it has a pre-filled value. If it does, present the attribute as read-only. (You do not need to include it when you execute AddItemCall.) If it does not, the user can select a value.
Determine which characteristics are required. If the IsRequired XML attribute is "true" or the attribute is a child attribute in a Type 5 Value-to-Meta-data (VM) dependency, or the characteristic's validation rules contain a RequiredRule field, the application should indicate that the field is required.

For example, an end user application might display "*" or "Required" adjacent to the field.

Determine which characteristics have parent-child dependencies, and then make sure dependencies are handled correctly when presenting the data to the user.
If you are using the Item Specifics SYI XSL solution, this is handled for you.
If you are not using the XSL solution, your application should check to determine whether a selected attribute is a child attribute in a Type 4 Value-to-Attribute (VA) dependency. Do not display Type 4 dependency attributes unless the user chooses an appropriate value in the parent attribute. Attempting to list an item with an invalid Type 4 attribute will cause the call to fail.

For example, an application should not display the Face Value field for a Tickets listing unless the user chooses a state or province that requires that information.

For information about edit types and dependencies, see Attribute and Product Finder Content Models.

In addition, you can control how eBay should handle the request when invalid attribute data is passed in. For example, you may prefer eBay to simply drop invalid attributes and proceed with listing the item, or you may prefer eBay to reject the listing if any attributes are incorrect. See Setting the Attribute Error Severity Preference for more information.

A Basic Validation Algorithm

This section is applicable for applications that use the Item Specifics SYI XSL stylesheet and applications that do not.

If you are using the Attributes Library, the sample AttributesMaster, ValidationRule, and VResult classes handle all the following logic for you. Therefore, the following information will mainly be of interest if you are creating your own implementation of the IAttributesMaster interface.

The following algorithm describes how an application could check input data after the user has selected attributes and values and before submitting the listing to eBay.

After characteristics have been selected for a listing, store the characteristic set ID, attribute IDs, value IDs, and literal values that were specified.

For example, an end-user (i.e., GUI) application would store these IDs when a user fills in the application's Item Specifics form.

For the current characteristic set being processed, make sure all required fields are filled in:
Determine which characteristics are required. That is, determine which attributes contain the RequiredRule field, include the IsRequired XML attribute, or are child attributes in Type 5 Value-to-Meta-data (VM) dependencies). See Characteristic Parent-Child Relationships (Dependencies).
Compare the IDs of the required characteristics with the IDs of the attributes that were selected.
If the ID of a required characteristic is missing from the selected attribute IDs, return an error message that identifies the missing data. For example, an end-user application would present the Item Specifics form to the user again and display an error message next to the required field so that the user can correct the error. See Displaying Input Error Messages for more information.)
For each attribute that the user selected, make sure the value(s) pass the other validation rules:
From your local data store, retrieve all the validation rules (if any) for the characteristic with the corresponding ID.
Make sure the data entered (i.e., the user's input or choice) satisfies the criteria described by all the rules defined for that characteristic. See Table 22-4 maps each rule and each rule argument to the applicable data types. If you are using the Item Specifics SYI XSL stylesheet, you can determine each attribute's data type by examining the post data formats (e.g., the format attr_dCSId_attributeId_c indicates that the value is a full date). If you're not using the XSL, you can parse the characteristic set XML to determine the data types (see the Type field).
If the data is not valid, return an error message that identifies the problem. For example, an end-user application could present the Item Specifics form to the user again and display an error message below the affected control so that the user can identify and correct the error. (See Displaying Input Error Messages for more information.)
After verifying the selections against the validation rules, store all the correctly selected attributes and values and proceed with your application's item-listing workflow.

Displaying Input Error Messages

If you are using the Attributes Library, the sample AttributesMaster, ValidationRule, and VResult classes handle all the following logic for you. Therefore, the following information will mainly be of interest if you are creating your own implementation of the IAttributesMaster interface.

Some applications collect all error messages and return (or display) them after validating all fields. In a Web-based application, this approach is usually more convenient for the user than displaying each error one at a time and requiring the user to re-post the data before the next error is displayed.

If your end-user application validates the user's data before submitting it to eBay, you may choose to display error messages on the same screen or page as the fields that contain the incorrect data.

Note: You are not required to display error messages in your application in order to use the Item Specifics API. You are not required to use the same error message strings that eBay uses when displaying errors. If you prefer to use the same strings, most eBay errors associated with attributes are in these error code ranges: 912-917, 924-925, 5000-5117. See Error Message Strings.

If you are using the Item Specifics SYI XSL stylesheet, the stylesheet provides functionality to enable you to display error messages below the control for the attribute that caused the error. If you want to use this functionality, your application needs to generate an Errors node in a special format and add it to the XML meta-data before generating the Item Specifics form.

For example, you can use a process like this to return errors to the user:

When the user submits the Item Specifics data, generate a revised XML document that contains the data the user selected.

Although this is optional, it is usually a good idea so that the user does not need to fill in the entire form again. To specify the data the user selected, place the IDs in SelectedAttributes.AttributeSet nodes, as shown in the example below. See Generating Error Messages in the Item Specifics Form for additional information.

In the revised XML document, include information about the errors.

Place this information in an Errors node in the new XML document. One way to do this might be to create your XSL stylesheet that handles the validation and apply it to the revised XML document. See Patching the XML to Customize the Look and Feel for information about using stylesheets to customize the presentation of the XML. The Errors node should be a child of the eBay tag.

Within the Errors node, specify this information:

An ErrorSet node with an id attribute. The id attribute specifies the ID of the characteristic set in which the error has occurred.
An Error node with errorcode and id attributes. The errorcode attribute specifies the rule that was violated. The id attribute identifies the attribute that has the wrong value.
The error message text, which should be specified in the Error element body. The error message text should be consistent with the validation rules. For example, if a rule indicates that the max length of a string is 50 characters, your error message could say "Please enter no more than 50 characters.".

Note: Most eBay error messages associated with attributes are in these error code ranges: 912-917, 924-925, 5000-5119. See Error Message Strings.

Example 22-1 Adding an Errors Node to the XML 

<eBay>   <Errors>     <ErrorSet id="1">       <Error errorcode="StringLengthRule" id="63">Please enter no more than 50 character(s).</Error>       <Error errorcode="MultiSelectMaxNumberValuesRule" id="62">Please make no more than 2 selections.</Error>     </ErrorSet>     <ErrorSet id="2">       <Error errorcode="MultiSelectMinNumberValuesRule" id="30">Please make no fewer than 2 selections.</Error>     </ErrorSet>   </Errors>   <SelectedAttributes>     <AttributeSet id="1">       <Attribute id="9">         <Value id="1038"/>       </Attribute>     </AttributeSet>   </SelectedAttributes>   <Attributes>     <AttributeSet id="1">       <DomainName><![CDATA[Tickets]]></DomainName>         <Attribute vivisible="true" id="10" count="1" source="3" displaysequence="5">           <SellingDisplayLabel>Venue City</SellingDisplayLabel>         ... usual additional nodes ...

Reapply the Item Specifics SYI XSL stylesheet to the new XML document. The stylesheet includes an AttributeError template for presenting errors that are described in the XML document.

If a validation rule specifies additional arguments (e.g., Max or Length), it is a good idea to return those values in the corresponding error message text so that the user understands how to fix the problem. For example, MaxIntValidationRule specifies a Max argument that your application can pass in to the corresponding error message:

Please enter a value less than {0}.

Validation Rules in the Attribute Meta-Data

The information in this section is applicable when a seller is listing the standard way with Item Specifics and when they are specifying optional attributes when listing with Pre-filled Item Information. It is applicable both for applications that use the Item Specifics SYI XSL stylesheet and applications that do not.

If you are using the Attributes Library, the sample AttributesMaster, ValidationRule, and VResult classes handle all the following logic for you. Therefore, the following information will mainly be of interest if you are creating your own implementation of the IAttributesMaster interface.

In the attribute meta-data returned from GetAttributesCSCall and GetProductSellingPagesCall, characteristics that accept user-entered text usually include rules for validating the user's input against regular expressions, string length constraints, and other criteria.

Summary of the Available Validation Rules lists the available rules and describes their meaning. A few rules, such as RequiredRule and VinValidationRule, indicate that the attribute is required (i.e., that a value must be supplied). However, unless otherwise stated, validation rules are only applicable if a value was specified for the attribute. For example, PrecisionRule is only applicable if a user specifies a value for the attribute. It does not imply that a value must be specified.

You are not required to validate the user's selections prior to listing an item. However, your AddItemCall request (and related calls) may fail if the user selects invalid combinations of values or enters invalid data.

If you do choose to validate the user's input, you are not required to use the validation rules supplied by eBay. The rules are provided for your convenience only.

Using Regular Expression Validation Rules

Attributes that accept user-entered text may include rules for validating the user's input against regular expressions (RegularExpressionRule). Some attributes may specify string length constraints (StringLengthRule) instead of a regular expression.

For regular expression rules, the Regex field contains the pattern portion of a matching operation. Regular expressions can include (but are not limited to):

Quantifiers, such as * (match 0 or more times) and {n} (match exactly n times)
Meta-characters, such as ^ (match at the beginning of the string) and $ (match at the end of the string)
Character classes, such as [0-9] (match a digit) and [a-zA-Z] (match an upper or lowercase letter)
Character class abbreviations, such as \d (match a digit) and \w (match an alphanumeric character or "_")

For example, the pattern for matching a time value in the format HH:MM:SS (e.g., 14:30:00) might be might be expressed as:

<Regex>\d\d:\d\d:\d\d</Regex>

The pattern for matching a U.S. Social Security Number might be expressed as:

<Regex>\d{3}\-\d{2}\-\d{4}</Regex>

The pattern for matching a 5-digit zip code might be expressed as:

<Regex>\d{5}</Regex>

The pattern for matching a date in the format DD/MM/YYYY might be expressed as:

<Regex>\d{2}/\d{2}/\d{4}</Regex>

This rule can specify be any Java regular expressions defined in J2SE 1.4.

java.util.regex.Pattern

http://java.sun.com/j2se/1.4.2/docs/api/java/util/regex/Pattern.html#matches

Several sources of information about working with regular expressions are available on the Internet.

Summary of the Available Validation Rules

Validation rules are returned in ValidationRules nodes. A ValidationRules node can contain zero or more Rule nodes. If a characteristic has no validation rule, the validation rule is empty (<ValidationRules/>). Each Rule node contains a Name field. In addition, some Rule nodes contain additional fields for specifying valid ranges and other information. For example, the string length rule contains an additional Length field.

Example 22-2 A ValidationRules Node 

<ValidationRules> <Rule> <Length>30</Length> <Name>StringLengthRule</Name> </Rule> </ValidationRules>

In the table below, the "Content of Rule Node (with Sample Data)" column shows the fields that appear within the Rule node for each rule, along with sample values. The samples are formatted on multiple lines to fit the width of the table column. The actual XML may not use the same line breaks.

The "Description" column maps each rule to the applicable attribute data types and specifies the data type of each rule argument (other than Name, which is a string). If you are using the Item Specifics SYI XSL stylesheet, you can determine each attribute's data type by examining the post data formats (e.g., the format attr_dCSId_attributeId_c indicates that the value is a date). If you're not using the XSL, you can parse the characteristic set XML to determine the data types (see the Type field).

Unless otherwise stated, validation rules are only applicable if a value was specified for the attribute. For example, PrecisionRule is only applicable if a user specifies a value for the attribute. It does not imply that a value must be specified.

Note: Most eBay error messages associated with attributes are in these error code ranges: 912-917, 924-925, 5000-5119. See Error Message Strings.

If you are not using the SDK, it may be useful to look at the implementation in the Attributes Library in the eBay SDK for .NET for examples of how to implement support for these rules. See SimpleValidator.cs in eBay.Service.SDK.Attribute.

Table 22-4 Validation Rules 

Rule Name	Content of Rule Node (with Sample Data)	Description
DateNullCheckRule	<Name>DateNullCheckRule</Name> <PeerAttributeId>3</ PeerAttributeId>	Indicates that both the start ("from") date and end ("to") date in a range must be present. This rule is specified for the "from" date attribute. The PeerAttributeId contains the ID of the "to" date attribute. Note: This rule is different from DateRangeValidationRule, which checks the validity of a date range. Applicable to attribute type: Date PeerAttributeId type: Integer
DateRangeValidationRule	<Name>DateRangeRule</Name> <PeerAttributeId>3</PeerAttributeId>	For a date range, indicates that the start ("from") date must be earlier than the end ("to") date. The "from" date and "to" date are defined as separate attributes. This rule is specified for the "from" date attribute. The PeerAttributeId contains the ID of the "to" date attribute. Note: This rule is different from DateNullCheckRule, which checks whether a date is not present. Applicable to attribute type: Date PeerAttributeId type: Integer
DateValidationRule	<Name>DateValidationRule</Name>	Indicates that the argument must use one of the proper ISO date formats (see Specifying Date Attributes when Listing Items). Applicable to attribute type: Date
DecimalSeparatorNotAllowedRule	<Name>   DecimalSeparatorNotAllowedRule </Name> <Separator>,</Separator>	Indicates that the specified symbol cannot be used as a decimal separator. Applicable to attribute type: Numeric Separator type: String—Not necessarily period (.), space ( ), or comma (,).
DoubleRangeValidationRule	<Name>   DoubleRangeValidationRule </Name> <Min>1.0</Min> <Max>10.0</Max>	Indicates that a double value must be within a specified range (inclusive). Applicable to attribute type: Numeric Min, Max type: Double
IntRangeValidationRule	<Name>IntRangeValidationRule</Name> <Min>0</Min> <Max>9</Max>	Indicates the valid range of values (minimum to maximum) for a number. Applicable to attribute type: Numeric Min, Max type: Integer
MaskCheckRule	<Name>MaskCheckRule</Name> <Mask>Dec-20XX<Mask>	Specifies a sequence of characters (in the UTF-8 character set) that must be included in the value. 'A' and 'X' have a special meaning: A = Any upper or lower case letter X = Any digit from 0-9 All other characters in the mask require an exact match. For example, a "AAA-XXXX" mask would allow "Dec-2003", "Dec-2025", and "Dec-205000" to pass validation, but "December 2003" would fail. Applicable to attribute type: Numeric, Date, or String Mask type: String
MaxDoubleValidationRule	<Name>MaxDoubleValidationRule</Name> <Max>3.0</Max>	Specifies the maximum double value of the attribute. Applicable to attribute type: Numeric Max type: Double
MaxIntValidationRule	<Name>MinIntValidationRule</Name> <Min>3</Min>	Specifies the minimum integer value of the attribute. Applicable to attribute type: Numeric Min type: Integer
MinDoubleValidationRule	<Name>   MinDoubleValidationRule </Name> <Min>3.0</Min>	Specifies the minimum double value of the attribute. Applicable to attribute type: Numeric Min type: Double
MinIntValidationRule	<Name>MinIntValidationRule</Name> <Min>3</Min>	Specifies the minimum integer value of the attribute. Applicable to attribute type: Numeric Min type: Integer
MotorsUKValidationRule	<Name>MotorsUKValidationRule</Name>	Indicates that the length must be 7 and only digits and letters are allowed (i.e., [A-Za-z0-9]).
MultiSelectMaxNumberValuesRule	<Name>   MultiSelectMaxNumberValuesRule </Name> <Max>3</Max>	Indicates the maximum quantity of selections that the user can make in a control that allows multiple selections. Applicable to attribute type: Numeric, Date, or String Max type: Integer
MultiSelectMinMaxNumberValuesRule	<Name>   MultiSelectMinNumberValuesRule </Name> <Max>3</Max> <Min>3</Min>	Indicates the minimum and maximum quantity of selections that the user can make in a control that allows multiple selections. Applicable to attribute type: Numeric, Date, or String Max, Min type: Integer
MultiSelectMinNumberValuesRule	<Name>   MultiSelectMinNumberValuesRule </Name> <Min>3</Min>	Indicates the minimum quantity of selections that the user must make in a control that allows multiple selections. Applicable to attribute type: Numeric, Date, or String Min type: Integer
NumberSeparatorNotAllowedRule	<Name>   NumberSeparatorNotAllowedRule </Name> <Separator>,<Separator>	Indicates that the symbol cannot be used within a number. Applicable to attribute type: Numeric Separator type: String—Not necessarily period (.), space ( ), or comma (,).
PrecisionRule	<Name>PrecisionRule</Name> <Precision>2</Precision>	Obsolete. Not a validation rule. Suggests a display format for the user's input data (i.e., the scale, or how many digits are allowed after a decimal). Applicable to attribute type: Numeric (double) Precision type: Integer
RegularExpressionValidationRule	<Name>   RegularExpressionValidationRule </Name> <Regex>a*b</Regex>	Indicates that an argument must match the specified regular expression pattern. (See Using Regular Expression Validation Rules.) Applicable to attribute type: String Regex type: String
RequiredRule	<Name>RequiredRule</Name> <Required/>	Indicates that the attribute is required. Applicable to attribute type: Numeric, Date, or String Required type: Boolean (present or not present)
StringLengthRule	<Name>StringLengthRule</Name> <Length>45</Length>	Limits the length of string the user can enter in text boxes (including conditional or "other" fields that may be shown if a user selects a value like "Other" in a drop-down list). Applicable to attribute type: String Length type: Integer
ThousandsSeparatorNotAllowedRule	<Name>   ThousandsSeparatorNotAllowedRule </Name> <Separator>,<Separator>	Indicates that the specified symbol cannot be used as a thousands separator. Applicable to attribute type: Integer Separator type: String—Not necessarily period (.), space ( ), or comma (,).
UrlValidationRule	<Name>UrlValidationRule</Name> <Protocol>http</Protocol> <InvalidHost>ebay.com</InvalidHost> <InvalidHostOverride> developer.ebay.com </InvalidHostOverride>	Indicates that the argument must be a properly formatted URL. If specified, the URL must use the correct syntax (i.e., it must contain "://" and it must not contain a space); the specified Protocol must be used; and the host must not contain the InvalidHost value (if any), although it can contain the InvalidHostOverride value, if any. As a theoretical example, we might generally disallow ebay.com (InvalidHost), but allow certain developer.ebay.com values (InvalidHostOverride). Applicable to attribute type: String
VinValidationRule	<Name>VinValidationRule</Name>	Indicates three requirements related to Vehicle Identification Number (VIN) usage for US eBay Motors listings: The VIN attribute is required when the year of vehicle manufacture is equal to or greater than 1981. The value passed in the VIN attribute must contain 17 characters. The value passed in the VIN attribute must be a valid VIN. Applicable to attribute type: Date If you are not using the SDK, it may be useful to look at SimpleValidator.cs in the eBay SDK for .NET for an example of how to validate a VIN. Also see: Valid Item Specifics for Listing eBay Motors US Cars & Trucks http://pages.ebay.com/ebaymotors/help/sell/motors/VIN.html