pml-lang
commented
3 years ago add to the JSON file generated via pmlc tag_info a dedicated entry for each node I think that something like "child_nodes_allowed" might be appropriate
I've added it. Will be included in the next public version 2.2.
Here is a new version of the JSON file with field child_nodes_allowed: pml_tags.zip
knowing which nodes are allowed inside each and every node, and which are not, is another essential piece of info for being able to detect invalid sub-nodes within the syntax
Yes, I fully agree. My plan is add "document validation" to PDML, because it is an essential feature of any data format. This feature could then be used in PML to validate PML documents. However I have not yet decided on how to implement this. It's not a trivial task at all. PDML has already types (work in progress) to validate the text content of nodes. However this feature does not allow yet to define which child nodes are valid for a given node.
Another option to validate PML documents would be to use XML schemas. This option will be available as soon as there will be a PML-CLI command to transform any PML document into a standalone XML document. This command will be added in the near future, as the code to convert PML to XML exists already.
tajmone
In Lenient Parsing we read:
The problem is knowing which nodes are childless an which aren't — both for taking advantage of this feature while editing, as well as for implementing its support in editor syntaxes/packages.
The User Manual mentions the
[imagenode as an example, but having access to the full list of these nodes types would be really useful (as opposed to guess work or trial and error).It would be really helpful if you could add to the JSON file generated via
pmlc tag_infoa dedicated entry for each node, specifying whether is allows child nodes or not, along the lines of"is_raw_text_block"andHTML_attributes_allowed". This would also allow easily auto-generating a list of such nodes (e.g. via Mustache), which could be added as an Appendix to the PML Reference Manual.I'm not sure how this key should be named but, based on the current keys names, I think that something like
"child_nodes_allowed"might be appropriate, especially for a boolean key.As a general rule, bear in mind that when it comes to creating packages for editor support, having access to similar info is essential in order to implement syntaxes properly.
E.g. knowing which nodes are allowed inside each and every node, and which are not, is another essential piece of info for being able to detect invalid sub-nodes within the syntax — one you know which nodes are supported, you only need to include them, and treat the rest as invalidly placed nodes.
Currently this type of info is not accessible, which only leaves trial and error — with current number of nodes supported by PML, their possible combinations amounts to a huge number.
In most modern editors' syntax definitions, each node is implemented as independent "context" (JSON/YMAL block) which can then be included wherever required (at the root level, within other nodes, etc.). Knowing in advance what other nodes each node can take as its child is a huge helper in task of building PML syntaxes.