-
Notifications
You must be signed in to change notification settings - Fork 10
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
add basic asdf string-like tags #581
Comments
Not sure if it causes more trouble than benefit. Apart from having a searchable tag, what else do we gain? Also, it is most likely that those items are already stored with a corresponding key that can be searched for too. On the downside, we have to maintain additional schemas and python functions. Even if the maintenance overhead is small, I am currently not convinced that we get a real benefit out of it. In the end, a string is a string, and if its purpose can either be deduced from the content or a corresponding key in the file. I do not see the need to further categorize the different types of strings. The only reason for me to consider this would be if we can actually do something with those wrapper classes. For example, let Python fetch some metadata using the DOI. |
two advantages besides searching that come to my mind:
To start it is probably enough to add the schemas with (without For a python implementation I would imagine it would be as simple as having a mapping between tag names and regex patterns to match but we don't have to worry about that now, not really a high priority :) |
This should also be possible using custom validators (
Not really an advantage but a matter of taste here 😉 The key of a string object should already provide that information. Don't get me wrong. I am not strictly against it, but so far I see no real benefit. It currently feels to me as something we do just because we can and not because we need it. But I might be wrong here. So feel free to implement it. |
since tagging strings is easy and having tags can be used to search files etc. we could add some more 'base' classes that simply inherit from string and represent special string styles
some ideas:
since I imagine most users don't want to be bothered instancing new classes to specify their strings this would probably only be usable if we auto-convert strings using regex matches or similar when serializing (which I am not sure we are able to do and might have a massive performance impact)
The text was updated successfully, but these errors were encountered: