Validate the BMEcat 2005 XSD structure first, then check ECLASS-specific rules: class IRDI existence, property IRDI format and reference match, unit IRDI agreement with property definitions, enum value correctness, and multivalence constraints. The whole process catches errors that XSD alone misses.
Why ECLASS BMEcat validation is different
BMEcat 2005 is the XML format. ECLASS is the classification layer inside it. XSD validation only checks the XML structure. It confirms that your PRODUCT_FEATURES element exists and contains FEATURE elements with FNAME and FVALUE children. It does not check whether the IRDI in FNAME is a real ECLASS property, whether the unit matches, or whether the value is the right type.
ECLASS semantic validation sits on top of XSD. It cross-references every IRDI in your file against the ECLASS reference data. This is where most real-world errors hide.
Upload your file to the ECLASS BMEcat validator to run both XSD and semantic checks in one pass.
Step 1: Confirm ECLASS version and BMEcat namespace
ECLASS and BMEcat have independent version numbers. Your file needs both to be correct.
ECLASS version is declared in REFERENCE_FEATURE_SYSTEM_NAME. The format should be ECLASS-XX.Y where XX.Y is the version. For ECLASS 16.0:
<REFERENCE_FEATURE_SYSTEM_NAME>ECLASS-16.0</REFERENCE_FEATURE_SYSTEM_NAME>
BMEcat namespace varies across real-world files. The original spec uses http://www.bmecat.org/bmecat/2005, but many systems output 2005.1 or 2005.2 variants. The ECLASS BMEcat validator automatically normalizes these variants, but your trading partner's system might not.
Confirm with your trading partner which ECLASS version they support. Using ECLASS 14.0 IRDIs when the receiver expects 16.0 will trigger "IRDI not found" errors on properties that changed between versions.
Step 2: Run XSD validation
XSD validation against the BMEcat 2005 schema catches structural issues:
- Missing required elements (SUPPLIER_PID, DESCRIPTION_SHORT)
- Wrong element ordering
- Namespace mismatches
- Malformed XML
Fix all XSD errors before moving to semantic validation. A structurally invalid file cannot be reliably parsed for IRDI checks.
Step 3: Validate class IRDIs
Every product should have a REFERENCE_FEATURE_GROUP_ID containing an ECLASS class IRDI. The class IRDI format is 0173-1#01-AAA999#999.
Two checks apply:
Format check. Does the IRDI match the expected pattern? Common format errors: missing hash separators, lowercase letters, wrong number of digits.
Existence check. Does the class exist in the ECLASS 16.0 reference? ECLASS 16.0 contains 48,283 classes. A well-formed IRDI that does not appear in the reference is likely from a different ECLASS version or mistyped.
Warning: REFERENCE_FEATURE_GROUP_ID "0173-1#01-ZZZ001#001" not found in ECLASS 16.0 reference
If you see this warning, look up the class in the ECLASS version you are migrating from. Find the equivalent class in 16.0. Class IRDIs sometimes change between major releases.
Step 4: Validate property IRDIs and data types
Each FEATURE element has an FNAME that should be an ECLASS property IRDI (type 02). For each property, the validator checks:
IRDI format. Must match 0173-1#02-AAA999#999.
Reference existence. The property must exist in ECLASS 16.0. If not found, the property may be from an older version or custom-defined.
Data type. If the property is defined as numeric (integer or decimal), every FVALUE should be a valid number. If the property is an enumeration, the FVALUE should be either a value IRDI (type 07) or a recognized label from the enum list.
Worked example. Property 0173-1#02-AAB325#008 (rated voltage) is defined as numeric in ECLASS 16.0. If your file contains:
<FEATURE>
<FNAME>0173-1#02-AAB325#008</FNAME>
<FVALUE>230V</FVALUE>
</FEATURE>
The validator flags this: FVALUE "230V" for numeric property "Rated voltage" is not a valid number. The fix is to separate the number from the unit:
<FEATURE>
<FNAME>0173-1#02-AAB325#008</FNAME>
<FVALUE>230</FVALUE>
<FUNIT>0173-1#05-AAA480#003</FUNIT>
</FEATURE>
Step 5: Check unit IRDIs
Unit IRDIs (type 05) appear in the FUNIT element. Two validation checks:
Format. Must match 0173-1#05-AAA999#999.
Property agreement. Each ECLASS property has a defined unit. If property 0173-1#02-AAB325#008 expects unit 0173-1#05-AAA480#003 (Volt), using a different unit IRDI triggers a mismatch warning.
This catches a common error: copying features from one product to another and forgetting to update the unit when the property expects a different one. A temperature property with a voltage unit is obviously wrong, but less obvious mismatches (milliamp vs. amp, millimeter vs. meter) slip through without automated checking.
Step 6: Verify enumeration values
Enumeration properties have a defined set of valid values. When the FVALUE is a value IRDI (starting with 0173-1#07), the validator checks its format. When the FVALUE is a text label, the validator checks whether it matches any label in the enum list.
Warning: FVALUE "medium" for property "Protection class" does not match any enum value
This typically means the source system stores human-readable labels that do not match the ECLASS enum labels exactly. Check for case differences, language mismatches (German label vs. English enum), or abbreviated values.
Step 7: Check multivalence constraints
Some ECLASS properties are multivalent (they accept multiple values). Most are not. If a non-multivalent property has more than one FVALUE element, the validator flags it:
Warning: Property "Rated voltage" (0173-1#02-AAB325#008) has 3 values but is not multivalent
This usually means a range or list was incorrectly encoded as multiple values. For non-multivalent properties, use a single FVALUE with the primary value. If the product genuinely has multiple values (e.g., a multi-voltage device), check whether a multivalent property exists for that concept, or use a different encoding approach.
Step 8: Review custom features
Products often include features that use custom FNAMEs instead of ECLASS IRDIs. The validator counts these:
Warning: Product ABC123: 4 feature(s) use custom (non-ECLASS IRDI) FNAMEs
Custom features are not necessarily wrong. They carry manufacturer-specific data that ECLASS does not have a property for. But a high count of custom features suggests incomplete ECLASS mapping. If most features in your file are custom, review whether ECLASS properties exist for the data you are encoding.
Worked example: validating a cable product
A cable manufacturer exports 500 products classified under ECLASS 16.0 for an industrial distributor. Running the file through the ECLASS BMEcat validator returns:
- 0 XSD errors (structure is clean)
- 12 IRDI format errors (missing hash separator in 12 property IRDIs)
- 34 warnings: unit IRDI mismatch on cross-section properties
- 500 warnings: 3 custom features per product (1,500 total non-IRDI FNAMEs)
The 12 format errors are the priority. Searching the source data reveals a PIM export bug that drops the # between the type code and item code. Fix the export template. The 34 unit mismatches turn out to be millimeter-squared vs. meter-squared on conductor cross-section properties. The custom features are manufacturer-specific attributes (brand series, color, package type) that have no ECLASS equivalent, so those warnings are acceptable.
After fixing the 12 format errors and 34 unit mismatches, re-validation shows zero errors and only the expected custom feature warnings.