Summary
When validation fails, the field name is currently embedded within the issueMessage string, making it difficult to programmatically identify which field caused the error without string parsing.
Current Behavior
{
issueMessage: 'Required attribute "price" is missing',
severity: 'ERROR',
path: [{ type: 'Product' }, { property: 'offers' }, { type: 'Offer' }]
}
To extract the field name, consumers must parse the message:
const match = issue.issueMessage.match(/attribute "([^"]+)"/);
const fieldName = match?.[1]; // "price"
Problem
This approach is:
- Fragile — breaks if message wording changes in future versions
- Redundant — every consumer implements the same parsing logic
- Not i18n-friendly — would break if messages are localized
Proposed Solution
Add a fieldName property to error objects returned by required(), recommended(), and or() methods in src/types/base.js:
{
issueMessage: 'Required attribute "price" is missing',
severity: 'ERROR',
path: [{ type: 'Product' }, { property: 'offers' }, { type: 'Offer' }],
fieldName: 'price' // New property
}
For or() conditions checking multiple fields:
{
issueMessage: 'One of the following conditions needs to be met: ...',
severity: 'ERROR',
path: [...],
fieldName: 'price', // First field (simple access)
fieldNames: ['price', 'priceSpecification.price'] // All fields
}
Use Case
This enables precise UI feedback in structured data editors — for example, highlighting the exact form field that needs attention without fragile regex parsing.
Backward Compatibility
This change is fully backward compatible — it only adds new optional properties to existing error objects.
Additional Validators
Beyond base.js, some validators create error objects directly without using the base methods. These should also include fieldName for consistency:
| File |
Error Context |
fieldName |
BreadcrumbList.js |
At least two ListItems required |
itemListElement |
BreadcrumbList.js |
Invalid URL validation |
item or item.@id |
DefinedRegion.js |
addressRegion/postalCode conflict |
addressRegion |
MerchantReturnPolicy.js |
Return fees validation |
(context-dependent) |
Product.js |
aggregateRating/offers/review required |
aggregateRating + fieldNames |
Product.js |
Notes count warning |
review |
ProductMerchant.js |
GTIN field missing |
gtin + fieldNames |
Rating.js |
Rating outside range |
ratingValue |
schemaOrg.js |
Unsupported property |
(property name from context) |
This ensures fieldName is consistently available across all validation errors, not just those using base methods.
Summary
When validation fails, the field name is currently embedded within the
issueMessagestring, making it difficult to programmatically identify which field caused the error without string parsing.Current Behavior
To extract the field name, consumers must parse the message:
Problem
This approach is:
Proposed Solution
Add a
fieldNameproperty to error objects returned byrequired(),recommended(), andor()methods insrc/types/base.js:For
or()conditions checking multiple fields:Use Case
This enables precise UI feedback in structured data editors — for example, highlighting the exact form field that needs attention without fragile regex parsing.
Backward Compatibility
This change is fully backward compatible — it only adds new optional properties to existing error objects.
Additional Validators
Beyond
base.js, some validators create error objects directly without using the base methods. These should also includefieldNamefor consistency:BreadcrumbList.jsitemListElementBreadcrumbList.jsitemoritem.@idDefinedRegion.jsaddressRegionMerchantReturnPolicy.jsProduct.jsaggregateRating+fieldNamesProduct.jsreviewProductMerchant.jsgtin+fieldNamesRating.jsratingValueschemaOrg.jsThis ensures
fieldNameis consistently available across all validation errors, not just those using base methods.