You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Our current use of tag prevents users from extending the core schemas. For example, say someone wants to extend our software-1.0.0 schema to include an additional optional release_date property. It would be natural to implement like this:
But this doesn't work, because the tag property enforces that the object's tag be software-1.0.0, and the object that we validate with this schema will instead have tag extended_software-1.0.0.
Does tag serve a useful purpose in the root object of a schema? Schemas are matched to objects by tag in the first place, so it seems redundant to check the tag again during validation.
For the record, I had previously suggested removing tag from the metaschema altogether because I didn't understand its purpose as a validation directive. Now I'm suggesting that we remove it from the root object of the core schemas, but keep it in the metaschema for use cases like #268.
The text was updated successfully, but these errors were encountered:
Our current use of tag prevents users from extending the core schemas. For example, say someone wants to extend our
software-1.0.0
schema to include an additional optionalrelease_date
property. It would be natural to implement like this:But this doesn't work, because the
tag
property enforces that the object's tag besoftware-1.0.0
, and the object that we validate with this schema will instead have tagextended_software-1.0.0
.Does
tag
serve a useful purpose in the root object of a schema? Schemas are matched to objects by tag in the first place, so it seems redundant to check the tag again during validation.For the record, I had previously suggested removing tag from the metaschema altogether because I didn't understand its purpose as a validation directive. Now I'm suggesting that we remove it from the root object of the core schemas, but keep it in the metaschema for use cases like #268.
The text was updated successfully, but these errors were encountered: