Generated JSON: Add New Boolean Keys "is_block_type" and "is_inline_type"

[tajmone]

Currently the PMLC generated JSON provides a "type" key with a value either "block" or "inline". That's great, and it should be kept as is.

But for mustache templates processing, it would be very useful to also have two new boolean keys representing the node type:

• "is_block_type"
• "is_inline_type"

where (obviously) one will always be true and the other false.

The rationale for this addition is that mustache is logic-less, so it can't filter tags by comparing their values against expected values, but only filter them by boolean states true/false or null/non-null.

Having these (redundant) keys would allow mustache template to filter tags according to types, without having to introduce Lambdas (which would render templates language-specific).

I know that having these redundant keys is not DRY, but hopefully it won't hurt either — after all, this auto-generated JSON document has a wide range of potential uses, ranging from tools that fully parse the JSON file to carry out complex operations, down to simpler uses like mustache templates, which operate at a simpler level.

The current "type" key is still useful in mustache templates, e.g. when generating a markdown table resuming all nodes proprieties, where it can be used to fill-in the cells of a "node type" column with either "block" or "inline". Whereas the proposed boolean keys would be used to produced filtered tags list, i.e. showing all tags of either block or inline type.

This principle of having a double standard in the generated JSON file, i.e. both a key+value and boolean variants thereof holds true for any PML node/tag/attribute which might be worth filtering — obviously, within reason, since if the possible values are in excess of three or four variants it might involve too many additional boolean keys to represent them in a filterable way.

Hopefully, the size of the JSON file shouldn't really matter, since it's intended for machine-processing rather than human consumption, and as long as the newly requested keys are easy to handle on the PMLC code generator side it should be fine.

Now that PML has grown mature, I'm seeing how the autogenerated JSON file is starting to become increasingly useful in a wide range of applications — from self-updating reference documents in lightweight markup languages, to syntax highlighter and editor syntax templates.

Each tool and application domain will probably focus on specific keys, ignoring the rest, so having too many keys/entries shouldn't be a problem either. Again, which keys are "important" is relative to the task at hand.

It's one of these tools that it's either very useful or totally useless, depending on the context, and in the case of mustache templates the lack of boolean alternative keys for filtering tags can make a huge difference in the usability of the JSON file.

So I guess that as time goes by, we'll be seeing more needed keys additions, based on new real case uses.

[pml-lang]

it would be very useful to also have two new boolean keys representing the node type: "is_block_type" "is_inline_type"

Ok. I just wonder why there should be two more fields. Wouldn't it be enough to just have is_inline_type. Because in moustache you have 'Inverted Sections' that "will be rendered if the key doesn't exist, is false, or is an empty list".

Is there another reason why there should be two new fields?

having these redundant keys is not DRY, but hopefully it won't hurt either

Having type and is_inline_type is no problem in this context, because the JSON is machine-generated and, as you said already, consumed by machines too.

[tajmone]

Ok. I just wonder why there should be two more fields. Wouldn't it be enough to just have is_inline_type. Because in moustache you have 'Inverted Sections' that "will be rendered if the key doesn't exist, is false, or is an empty list".

You're absolutely right.

Is there another reason why there should be two new fields?

I was just just thinking in terms of consistent naming conventions in view of future similar keys matching to more than two values, in which case it would require providing three boolean keys. That's all. But yes, having a single boolean key is fine.

[ch Predefined Attribute

I have one question....

Now that we have the autogenerated markdown doc tags-info.md showing the node/tag properties, it's easier to track all the info from the JSON file.

I've noticed in the Default Attributes section the following:

• [ch → title → ]
• [image → source → ]

It appears that in the generated pml_tags.json the [ch node mentions having a "default_attribute_id":"title":

"id":"ch",
"type":"block",
"title":"Chapter",
"description":"A chapter or sub-chapter of the document." … etc. …
"attributes":[
    {
        … etc. …
    }
],
"default_attribute_id":"title",  <-- here!

I'm not quite sure how to interpret this. Wasn't the title attribute replaced with the [title node? What does this key/value pair represent exactly?

[pml-lang]

yes, having a single boolean key is fine.

Ok. The field is_inline_type has been added. Will be included in PML 2.3. New file: pml_tags.zip

Wasn't the title attribute replaced with the [title node?

You're absolutely right. I just forgot to remove it from default_attribute_id. It's now fixed, and already corrected in the above file pml_tags.json.

[tajmone]

Ok. The field is_inline_type has been added. Will be included in PML 2.3.

Great! Thanks.

You're absolutely right. I just forgot to remove it from default_attribute_id

Isn't the process entirely automated via introspection?

[pml-lang]

Isn't the process entirely automated via introspection?

It is (to create the JSON file). The problem was in the formal definition of node ch (line 26 in PML_chapter_formal_node). I had to change that line to default_attribute_id = null.

[pml-lang]

Fixed in PML 2.3.0.