-
Notifications
You must be signed in to change notification settings - Fork 86
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
How to associate a schema to a YAML data? #29
Comments
The only one that i might consider to implement is the first suggestion. The main reason is that i do not like to open up the mix of data and schema in the same file, i think it is very messy. The best thing about the first option is that when there is a pointer to the resource, it can be implemented in a way that opens up for any type of location of that resource. It would make sense to implement the standard patterns of The bad thing is that the python yaml parser do not support out of the box to get the global tags after the data have been loaded. But on the other side, it is very easy to just parse the file and take the first |
I agree with you, I also prefer the first option while the From the YAML specs the two recognized
Last but not least, using the word Next step would be to add this validation support to the PyYAML module... |
I am still more in favor of the initial suggestion of
because it is more clean and easier to use. Atleast pyyaml do not throw up if i add
So that any tag can be implemented and the spec says that it should be compatible so if any other client is not compatible with a custom Tag then that one is broken, not pykwalify use of it :] |
So let's choose The next step will be to extend |
I would like to work on this implementation, but I need more inputs. What do we decide? Does it worth to inform maintainers of the YAML standard? |
This is even more true with YAML: You specify the type of the top element and all other elements that will not be resolved automatically to the correct type as a tag: %YAML 1.2
--- !my:data:schema
some: data
... Since YAML is designed to be deserialized into values native to the implementation language, it makes little sense to define a schema language for it. The native types the loader transforms the YAML into are the schema. In PyYAML, for example, you can derive from Now I am aware that this project has created a schema language nonetheless. Which is fine. But I think it would be a big mistake to implement somthing akin to However, is an explicit tag at the root element not enough for a validator to search for the relevant schema? Given the YAML above, the loader could say „oh, I know this tag, I have a schema for it“ and then validate against that schema. It is even possible to only parse parts of the YAML against a schema: %YAML 1.2
---
some: data
key with typed value: !my:data:schema
some: more
data: here
... According to the YAML spec, the top value (a mapping) will implicitly get the The only difference to the approaches discussed here is that there needs to be a mapping from tags to schema files outside the YAML. Which I think is fine; if you use XML within an application, you also ship the schema with the application and do not search for it in |
@flyx @nowox I think i will postpone implementing this feature for now. @flyx I agree with you that taking this over to the PyYaml/ruamel.yaml or even the YAML org itself is not the best idea.This validation language is not the "one and only and best yaml validation language" and i do not intend or have any motivation to bring it to that level. Another thing that has been bothering me about this feature is the security around it all. Say that we would implement some fetching from a http or git source for example, then we eitehr have to sandbox it very good to not escape and do bad things to your system by making it download something that you do not intent or that can cause harm to your system. This is kinda a problem factor for extensions but the main difference there is that you can't through the data or schema definition tell pykwalify to download something from a source and then execute it. I might even back off on the entire feature just based on this security implications. It is then better that you implement this kind of feature outside of pykwalify and just keep pykwalify as is where you must specify a schema and data explicitly. |
I do not plan to implement any of this. The feature seems to far out to really be usefull right now. |
In XML you can specify your XSD with a XML
xsi:schemaLocation
attribute. YAML specs lack with kind of information.So in my opinion two options are possible:
The second method allows to embed the schema inside the YAML description, this could be nice. Also, it allows to partially apply a schema to a particular node:
I don't know which option would be the best...
Any idea?
The text was updated successfully, but these errors were encountered: