Profiling (was extensions)

[mstade]

This format needs the ability to be extended through document profiles, so that people can define additional structures on top of the primitives. The need for this is manifested by the existence of a gazillion markdown clones; most of which define new semantics rather than new syntax. Additionally, there could be some overlap between this and vocabularies like which could make this format able to use existing vocabularies with ease. Not sure yet how this might look without markup-for-markup's-sake syntax.

This is arguably the most important feature of this format.

Some thoughts:

• Extensions define structure and semantics, not new primitives
• Be flexible; allow any kind of extension that doesn't change the underlying format

Examples of where the format could be extended through profiles to provide additional semantics:

• Screenplays
• Slides

[mstade]

I had an idea, that there could be a sort of grammar that could allow profiles to describe structural selections. The semantics of the selection would likely be more or less free form text, but the selection itself could be a structured and machine readable language such as css selectors or something similar. That would make it very easy to implement processors that understands profiles, by allowing them to discuss selections by name rather than generic syntax. It also allows for a generic profile reading library thingie to extract selections from profiles, so that profiles could update independently of the processors that relies on them; i.e. the contact surface between processor and profile is the name of the semantically loaded selection, rather than the selections themselves.

Here's an example:

recipe-ingredients = definition['Ingredients'] > list
recipe-instructions = recipe-ingredients + definition['Instructions'] > list

This bit of pseudo-css defines two selections: recipe-ingredients and recipe-instructions. The selectors are fairly concise, but in an expanded form says something like this:

• Let recipe-ingredients be a list that is a definition of the term Ingredients
• Let recipe-instructions be a list that is a definition of the term Instructions when it is preceded by a recipe-ingredients selection

Still fairly stiff jargon, but that's kind of the point. There can be all sorts of prose around this selection to describe the semantics more fully, but for a processor all that's really needed to figure out what text in a Markette document applies, is the actual selections. By giving selections names, the selections can change from something generic into something more specific (to that profile.)

I think I might turn this into a separate issue on profile document syntax, unless it's completely stupid.

[CodaAzzurra]

This could be powerful to help develop and process different kinds of increasingly complex structures made of smaller bits. You would be able to keep the ingredients and instructions in separate documents, with formats of their own, and then combine them in a third format. It is a bit of increased complexity in exchange for a lot more power.

That said I say stash this on a To Do list and stay focused on prime features.

[mstade]

This could be powerful to help develop and process different kinds of increasingly complex structures made of smaller bits.

Yes! Exactly!

You would be able to keep the ingredients and instructions in separate documents, with formats of their own, and then combine them in a third format. It is a bit of increased complexity in exchange for a lot more power.

That said I say stash this on a To Do list and stay focused on prime features.

Again, yes! A combination of profiles could complement each other; a Book profile and Recipe profile can be combined into a Cookbook profile. A profile is kind of like a tag, where the tag when dereferenced explains what it means. The tag doesn't change the underlying format, i.e. the element semantics can never change, so any conforming processor will understand any valid document – it just won't understand or care about the tags it doesn't recognize.

I reckon this is the most important feature, because without it there's little reason to even consider this format over alternatives like MultiMarkdown or what have you. Even if this is the only feature it has in addition to what Markdown already offers, it'd be a massive improvement.

[mstade]

I realize now that you might have meant that a selector type language for describing structures in a more processor friendly way might be overkill for a first version, not that profiles themselves are overkill. I do believe profiles are the single most important feature to get included at the start, but I also very much agree that they don't have to get too fancy. A selector language can, and probably should, be designed separately and evolve independently (much how CSS and HTML are separate specs.)

[pemrouz]

Another practical use case: Legislation. From DemocracyOS:

"We are working on a law markup language for legislative data. (That is, a data structure standard to incorporate data scraped from legislative sources around the word. The goal is to build an LML to be read by DemocracyOS as well as other apps that accept this open standard.)"