-
-
Notifications
You must be signed in to change notification settings - Fork 86
Upgrading to Schema.org Release 7.0 - Issues with extending primitives #126
Description
On the 21st of January, the next version of Schema.org has been released. I was going to open a PR to upgrade to however there seems to be some issues with the tool that I'm not sure how to handle - some of the problem might actually be a bug from Schema.org but at this stage, let's just look at it in scope of this project.
There is a new type called PronounceableText. While this type is (apparently) pending, the schema tool doesn't see it as pending. Additionally though, this is a type that extends a primitive which doesn't seem supported. (Of note, PronounceableText itself isn't classified as a primitive even though it extends Text which is)
When running the tool, it trips this exception when processing PronounceableText:
Schema.NET/Tools/Schema.NET.Tool/Services/SchemaService.cs
Lines 174 to 178 in 00cf921
| var parentClass = classes.FirstOrDefault(x => x.Id == parentClassId); | |
| if (parentClass is null) | |
| { | |
| throw new Exception(Resources.CheckThatNewPrimitiveTypeNotAdded); | |
| } |
In one way, if this type is pending it shouldn't even hit here. If it is technically marked correctly but the website is wrong saying it is pending, we need to work out how to handle types that extend primitives.
Should primitive types be "real" types in Schema.NET? For example, we could have a Text type (with no interface) and have it implicitly convert to/from string? That way, we could build PronounceableText on top of it? It should allow all our Values<> and OneOrMany<> implicit things to still work with concrete types etc. We'd probably want the primitive types to be struct though to help avoid additional allocations when dealing with numbers and dates (which would also likely follow this pattern).
I'm thinking unless we are going to ignore this primitive, we might need to do a bit of an overhaul of the schema tool.
What are your thoughts on this?