Unify html and bracket tags to DSL

[NoahTheDuke]

There's an adhoc DSL in the card data:

• html tags to represent rules references or reminder text (<strong>, etc)
• xml tags to represent complex visual styling or rules reference (<champion>, <trace>, etc)
• square brackets to represent icons ([credit], etc)

These are then stripped in the stripped_* fields for easy searching. However, this removes the user's ability to search for the icons themselves or for when they're referencing something, such as <strong>code gate</strong> being a reference to the subtype or <strong>AI icebreaker</strong> being a reference to a combination of subtype and type.

What if these were unified in some fashion to a single format? Then we could encode other domain-specific aspects of the cards into the text fields. Here's a rough example:

Now:

Install Dedicated Processor on a non-<strong>AI icebreaker</strong>.
Host <strong>icebreaker</strong> gains "2[credit]: +4 strength."

Potential:

Install Dedicated Processor on a non-<subtype>AI</subtype> <type>icebreaker</type>.
Host <type>icebreaker</type> gains "<cost><credit qty=2 /></cost>: +4 strength."

This is not quite ideal, I don't love self-closing tags, but it would be more consistent across the board and would allow for machine parsing and searching for specific elements. I can imagine a cost:"2 credit" that only searches costs, for example.

Maybe this could be in a new machine_text field or something, I'm not entirely sure. But it seems worth thinking about.

[NoahTheDuke]

Looking over the Scryfall syntax reference, it looks like they don't do any fancy encoding of costs, but because of the way mana costs are written they can include the number of colorless mana directly in cost symbols: {2}{W} is 2 colorless 1 white mana, so we can't use that. Having sat with it for a moment, I think <credit qty=2 /> is also bad. Sticking as closely as possible to the printed representation is good.

To shrink my idea a little, I think a solid first step would be to unify all of the existing tag formats to a single format. To use our icon formatting as the base:

Install Dedicated Processor on a non-[AI] [icebreaker].
Host [icebreaker] gains "2 [credit]: +4 strength."

Traces are a little awkward in this schema:

[subroutine] [Trace] [2] - If successful, trash 1 piece of hardware, do 2 meat damage (cannot be prevented), and end the run.

I don't know how to handle reminder text. Maybe just make all text in parentheses italics, as I think the rules team wants to make all text in parentheses either explicit or reminder only. I'd have to double check.

[distributive]

I did want to add a search query for searching for keywords specifically (e.g. k:trash|subroutine) in v2. We could do that by adding a new field for keywords or by somehow extracting them from the unstripped text on import.

It seems like what you're doing is redesigning Markdown but with different syntax. I think Plural's talked about maybe changing over to Markdown which I'd totally be for.

Markdown has the minor downside of losing tags like <champion> but I think we should move champion text to its own field now anyway.

I don't know what rules has planned but there are currently non-reminder parentheses (e.g. Hortum) so we can't make blanket assumptions about them just yet.

[NoahTheDuke]

It seems like what you're doing is redesigning Markdown but with different syntax. I think Plural's talked about maybe changing over to Markdown which I'd totally be for.

Sort of. Markdown is a DSL for text and specifically prose to encode prose-related concepts such as emphasis. I don't think markdown is good for our purposes because we have different needs, such as representing icons. Slapping asterisks into our text to replace <strong> and <em> is a stopgap because we'd still have to either use raw html or add custom parsing/AST logic to a markdown library to handle custom tags like [credit].

What I'm suggesting is very similar tho: we define a set of tags and some rules for how to render those tags, and use them universally. Very much like the curly brace tags that Scryfall uses.

[NoahTheDuke]

We could do that by adding a new field for keywords or by somehow extracting them from the unstripped text on import.

I'm all about this and can help if you want it to make this happen. My preference would be a list like subtypes.

Hortum

Dang, I didn't remember that. Okay, never mind on that suggestion.

[plural]

i haven't done enough thinking to really wanna recommend markdown, but i definitely don't like our ad-hoc mix of straight html, custom tags and other stuff. hehehehe. Markdown has some benefits and i still think we may want to look at it more closely before deciding.

+100 to making abilities explicit. We have a lot of options here and i'm looking forward to doing some prototyping. There we have a TON of options since we are designing an entirely new app.

[lf94]

Given the problem calls for styling that may be outside the featureset of markdown, I would not pursue using markdown. Gathering style requirements then designing a simple DSL would create a consistent NetRunner card language. The language should be semantic, rather than descriptive. This way the styling can easily be adjusted across all cards and implemented as needed across many platforms.

From what Ive seen, a few others in the discussion have mentioned similar things.

I think XML solves the problem very well if we want to leverage existing technologies.