HTML-in-HTML Serialization

Part of the WebMEM® Protocol
Location: /protocol/serialization/html/
Status: Current Draft
Last Updated: 2026-08-25

Overview

HTML-in-HTML is the current normative serialization of the WebMEM Protocol.

It represents the WebMEM knowledge model directly within an HTML document using inert HTML <template> containers, semantic HTML elements, and structured data-* attributes.

The serialization preserves the architectural distinction between:

Web Resource
        ↓
Semantic Data Template
        ↓
WebMEM Fragments
        ↓
Assertions and Structures
        ↓
Identity + Provenance + Relationships + Context
        ↓
Resolution-Relevant Knowledge

HTML-in-HTML is designed so that the machine-facing representation can coexist with ordinary human-facing HTML without rendering into the visible page.

A simplified structure is:

<template
  data-webmem-sdt
  data-sdt-id="https://example.org/resource/#webmem">

  <template
    data-webmem-fragment
    data-fragment-class="DataFragment"
    data-fragment-id="plan-benefits"
    data-entity-id="plan:H5521-290-0">

    ...

  </template>

</template>

The outer <template> represents the page-level Semantic Data Template.

Nested <template> elements represent WebMEM fragments.

Semantic HTML and data-* attributes inside those fragments represent the assertions, structures, identity references, provenance, relationships, and context associated with the knowledge.

Design Principle

HTML-in-HTML follows one governing rule:

Use HTML to serialize WebMEM knowledge without confusing the HTML syntax with the knowledge model itself.

Therefore:

Semantic Data Template
≠ <template>

WebMEM Fragment
≠ <template>

Assertion
≠ <data>

Identity
≠ data-entity-id

Provenance
≠ data-provenance-ref

Relationship
≠ data-relationship

The structures on the right serialize the concepts on the left.

The conceptual semantics are defined elsewhere in the WebMEM Protocol.

Read the Serialization specification →

Why `<template>`

The HTML <template> element provides an inert container whose contents are part of the HTML document but are not rendered as ordinary page content.

This makes it suitable for dual publishing:

HTML Document
│
├── Human-Facing HTML
│   └── rendered normally
│
└── WebMEM HTML
    └── inert <template> content

The WebMEM serialization does not require JavaScript execution to establish its structure.

The serialized knowledge is present declaratively in the HTML source.

The <template> element is therefore used as a publication boundary rather than as a deferred user-interface template.

HTML-in-HTML Document Structure

A WebMEM-enabled resource may contain:

<html>

  <head>

    <!-- Ordinary page metadata -->

    <script type="application/ld+json">
      Schema.org Dataset declaration
    </script>

  </head>

  <body>

    <main>

      Human-facing content

    </main>

    <template
      data-webmem-sdt
      data-sdt-id="https://example.org/resource/#webmem">

      WebMEM fragments

    </template>

  </body>

</html>

The Dataset declaration and the SDT may share the same stable identity.

The human-facing content and machine-facing representation remain distinct structures within the same resource.

The SDT Container

The outer WebMEM container represents the Semantic Data Template associated with the resource.

A conforming SDT container must:

use an HTML <template> element;
declare data-webmem-sdt;
declare a stable data-sdt-id;
contain one or more WebMEM fragment containers;
and preserve any page-level context required by the fragments it contains.

Example:

<template
  data-webmem-sdt
  data-sdt-id="https://example.org/medicare-options/arizona/mohave-county/#webmem">

  ...

</template>

`data-webmem-sdt`

data-webmem-sdt identifies an HTML <template> as a WebMEM Semantic Data Template container.

It is a presence attribute.

Example:

<template data-webmem-sdt>

The attribute does not contain the SDT identity.

The identity is provided separately through data-sdt-id.

`data-sdt-id`

data-sdt-id identifies the page-level Semantic Data Template.

The value should be stable within the publishing system and should be usable as an identity reference.

Recommended form:

data-sdt-id="https://example.org/resource/#webmem"

Where Schema.org Dataset JSON-LD is used to declare the page-level WebMEM dataset, the Dataset @id should match the SDT identity.

For example:

<script type="application/ld+json">
{
  "@context": "https://schema.org",
  "@type": "Dataset",
  "@id": "https://example.org/resource/#webmem",
  "url": "https://example.org/resource/"
}
</script>

<template
  data-webmem-sdt
  data-sdt-id="https://example.org/resource/#webmem">

  ...

</template>

Read Dataset Declaration and SDT Mapping →

Page-Level Context

The SDT container may establish context shared by multiple fragments.

Examples may include:

geography;
calendar year;
plan year;
jurisdiction;
language;
or another context genuinely shared by the contained fragments.

For example:

<template
  data-webmem-sdt
  data-sdt-id="https://example.org/resource/#webmem"
  data-geography-id="county:04015"
  data-plan-year="2026">

  ...

</template>

Fragments may inherit that context unless a more specific value overrides it.

Page-level context should be used only when it applies accurately to the knowledge that inherits it.

Fragment Containers

Each WebMEM fragment within an SDT is represented using a nested HTML <template> element.

A conforming fragment container must:

be contained by a WebMEM SDT;
declare data-webmem-fragment;
declare data-fragment-class;
declare a unique data-fragment-id within the applicable SDT;
preserve the subject identity where subject identity is required;
and contain the assertions or structures appropriate to its Fragment Class.

Example:

<template
  data-webmem-fragment
  data-fragment-class="DataFragment"
  data-fragment-id="plan-h5521-290-0-benefits"
  data-entity-id="plan:H5521-290-0">

  ...

</template>

`data-webmem-fragment`

data-webmem-fragment identifies an HTML <template> as a WebMEM fragment container.

It is a presence attribute.

Example:

<template data-webmem-fragment>

`data-fragment-class`

data-fragment-class declares the semantic Fragment Class represented by the container.

The value must correspond to a defined WebMEM Fragment Class.

For example:

data-fragment-class="DataFragment"

or:

data-fragment-class="DerivedStatsFragment"

or:

data-fragment-class="IdentityFragment"

The Fragment Class is semantically significant.

A parser should not infer Fragment Class solely from the elements contained inside the fragment.

Read the WebMEM Fragments specification →

`data-fragment-id`

data-fragment-id provides the identity of the fragment knowledge object.

Example:

data-fragment-id="mohave-county-plan-index"

Fragment identity is distinct from the identity of the entity described by the fragment.

For example:

Fragment:
mohave-county-plan-index

Represented Entity:
county:04015

The two identities must not be conflated.

`data-entity-id`

data-entity-id identifies the subject entity described by a fragment or subordinate structure.

For example:

data-entity-id="plan:H5521-290-0"

or:

data-entity-id="county:04015"

The identifier should preserve sufficient namespace and entity scope to avoid ambiguity.

When necessary, implementations may additionally expose:

data-entity-type="Plan"

or:

data-identifier-system="cms-plan"

Identity information should be represented at the highest level where it remains accurate for the knowledge inheriting it.

Read the Identity specification →

Fragment-Level Context

A fragment may establish context shared by its contained assertions or structures.

For example:

<template
  data-webmem-fragment
  data-fragment-class="DataFragment"
  data-fragment-id="plan-benefits"
  data-entity-id="plan:H5521-290-0"
  data-plan-year="2026"
  data-provenance-ref="#source-cms-pbp-2026">

  ...

</template>

The contained assertions may inherit:

entity = plan:H5521-290-0
plan_year = 2026
provenance = #source-cms-pbp-2026

unless a more specific structure overrides one of those values.

Assertions

An assertion communicates what the publisher states about an identifiable subject within applicable context.

HTML-in-HTML does not require every assertion to use one universal HTML element.

Scalar factual assertions should normally use the HTML <data> element because it provides a standard machine-readable value carrier.

Example:

<data
  data-webmem-assertion
  data-field="monthly_premium"
  value="0"
  data-type="currency"
  data-unit="USD">
  $0
</data>

The semantic meaning is established by the WebMEM attributes and inherited context.

The visible text inside the inert template may provide a human-readable rendering of the value but is not rendered as page content.

`data-webmem-assertion`

data-webmem-assertion identifies an element as a WebMEM assertion.

It is a presence attribute.

Example:

<data data-webmem-assertion ...>

The attribute allows a parser to distinguish factual assertions from other semantic structures within the fragment.

`data-field`

data-field identifies the predicate, property, or field being asserted.

Example:

data-field="maximum_out_of_pocket"

The field identifier should remain stable within its applicable vocabulary or publishing system.

Where a canonical definition exists, the assertion may additionally reference that definition.

For example:

data-defined-term-ref="term:maximum_out_of_pocket"

Assertion Values

For scalar assertions represented using <data>, the standard HTML value attribute contains the canonical machine value.

Example:

<data
  data-webmem-assertion
  data-field="maximum_out_of_pocket"
  value="4900"
  data-type="currency"
  data-unit="USD">
  $4,900
</data>

The machine value is:

The human-readable representation is:

$4,900

The datatype and unit establish how the value should be interpreted.

Datatypes

data-type declares the semantic datatype of an assertion value where the datatype cannot be determined safely from context alone.

Common values may include:

text;
integer;
decimal;
boolean;
date;
datetime;
duration;
percentage;
currency;
identifier;
uri;
enumerated;
or another datatype defined by an applicable WebMEM or domain profile.

Example:

<data
  data-webmem-assertion
  data-field="plan_count"
  value="42"
  data-type="integer">
  42
</data>

Boolean Values

Boolean values should use canonical values:

true
false

Example:

<data
  data-webmem-assertion
  data-field="includes_drug_coverage"
  value="true"
  data-type="boolean">
  Yes
</data>

Human-facing terms such as Yes, No, Included, or Not Included should not replace the canonical boolean value.

Dates and DateTimes

Dates should use ISO 8601-compatible machine values.

Example:

<data
  data-webmem-assertion
  data-field="effective_date"
  value="2026-01-01"
  data-type="date">
  January 1, 2026
</data>

DateTime values should include sufficient timezone information when timezone is material.

Currency

Currency assertions should separate the numeric value from the currency unit.

Example:

<data
  data-webmem-assertion
  data-field="monthly_premium"
  value="18.50"
  data-type="currency"
  data-unit="USD">
  $18.50
</data>

The symbol $ alone should not be relied upon to establish currency identity where ambiguity is possible.

Percentages

Percentages should preserve the numeric value and indicate percentage semantics explicitly.

Example:

<data
  data-webmem-assertion
  data-field="zero_premium_percentage"
  value="61.9"
  data-type="percentage"
  data-unit="percent">
  61.9%
</data>

Identifiers as Values

When an assertion value is itself an identifier, the serialization should preserve the applicable identifier system or namespace where needed.

Example:

<data
  data-webmem-assertion
  data-field="contract_id"
  value="H5521"
  data-type="identifier"
  data-identifier-system="cms-contract">
  H5521
</data>

Enumerated Values

Enumerated values should use a stable canonical token rather than depending only on presentation text.

Example:

<data
  data-webmem-assertion
  data-field="plan_type"
  value="ppo"
  data-type="enumerated">
  PPO
</data>

An applicable domain vocabulary may define the permitted enumeration values.

Units

data-unit identifies the unit associated with a scalar value when unit is semantically material.

Examples:

data-unit="USD"
data-unit="percent"
data-unit="days"
data-unit="months"
data-unit="miles"

A machine-readable value should not depend solely on punctuation, symbols, or presentation text to determine unit semantics.

Descriptions

An assertion may include a concise semantic description when the field identifier alone is insufficient to communicate its intended meaning.

Example:

<data
  data-webmem-assertion
  data-field="primary_care_copay"
  value="0"
  data-type="currency"
  data-unit="USD"
  data-description="Out-of-pocket cost for an in-network primary care visit.">
  $0
</data>

Descriptions should explain meaning rather than repeat the value.

Defined Terms

Assertions may reference a DefinedTermFragment or another canonical term identity.

Example:

data-defined-term-ref="term:primary_care_visit"

A corresponding DefinedTermFragment may provide the definition:

<template
  data-webmem-fragment
  data-fragment-class="DefinedTermFragment"
  data-fragment-id="term-primary-care-visit"
  data-entity-id="term:primary_care_visit">

  ...

</template>

The assertion does not need to reproduce the full definition if a stable relationship to the term preserves the meaning.

Assertion-Specific Identity

An assertion may override fragment-level entity identity when the assertion applies to a more specific or different entity.

For example:

<template
  data-webmem-fragment
  data-fragment-class="DataFragment"
  data-fragment-id="plan-data"
  data-entity-id="plan:H5521-290">

  <data
    data-webmem-assertion
    data-field="plan_type"
    value="ppo"
    data-type="enumerated">
    PPO
  </data>

  <data
    data-webmem-assertion
    data-field="monthly_premium"
    data-entity-id="segment:H5521-290-001"
    value="18.50"
    data-type="currency"
    data-unit="USD">
    $18.50
  </data>

</template>

The premium assertion applies to the Segment rather than the parent Plan.

The more specific identity overrides the inherited fragment identity for that assertion.

Identity inheritance must stop when the inherited subject ceases to be accurate.

Derived Assertions

Publisher-derived assertions must remain distinguishable from source-observed assertions.

A derived assertion should declare:

data-derived="true"

and should preserve the applicable provenance and derivation method.

Example:

<data
  data-webmem-assertion
  data-field="average_monthly_premium"
  value="15.26"
  data-type="currency"
  data-unit="USD"
  data-derived="true"
  data-method="arithmetic-mean"
  data-provenance-ref="#derivation-average-premium">
  $15.26
</data>

Source-observed assertions may declare:

data-derived="false"

or may omit the attribute when the Fragment Class and provenance establish source-observed status unambiguously.

A serialization must never imply that an originating source directly published a value the publisher actually derived.

Provenance References

data-provenance-ref connects a fragment, assertion, relationship, or other structure to its provenance representation.

Example:

data-provenance-ref="#source-cms-pbp-2026"

The referenced provenance object may be represented through a MetaFragment, dedicated provenance structure, or another conforming WebMEM mechanism.

For example:

<template
  data-webmem-fragment
  data-fragment-class="MetaFragment"
  data-fragment-id="source-cms-pbp-2026"
  data-entity-id="dataset:cms-pbp-2026">

  ...

</template>

References should resolve unambiguously within the applicable document or external identity space.

Provenance Inheritance

A fragment may establish provenance shared by multiple assertions.

Example:

<template
  data-webmem-fragment
  data-fragment-class="DataFragment"
  data-fragment-id="plan-benefits"
  data-entity-id="plan:H5521-290-0"
  data-provenance-ref="#source-cms-pbp-2026">

  <data
    data-webmem-assertion
    data-field="monthly_premium"
    value="0"
    data-type="currency"
    data-unit="USD">
    $0
  </data>

  <data
    data-webmem-assertion
    data-field="maximum_out_of_pocket"
    value="4900"
    data-type="currency"
    data-unit="USD">
    $4,900
  </data>

</template>

Both assertions inherit the same provenance.

If one assertion comes from another source:

<data
  data-webmem-assertion
  data-field="enrollment"
  value="2136"
  data-type="integer"
  data-provenance-ref="#source-cms-enrollment-2026-07">
  2,136
</data>

the assertion-specific reference overrides the fragment-level provenance.

Shared provenance may be inherited. Material provenance differences must remain explicit.

Read the Provenance specification →

Relationships

Relationships connect identifiable objects and must preserve at least:

source identity;
relationship predicate;
target identity;
and applicable scope when material.

HTML-in-HTML serializes explicit relationships using an element marked with data-webmem-relationship.

Example:

<link
  data-webmem-relationship
  data-source-id="contract:H5521"
  data-predicate="hasPlan"
  data-target-id="plan:H5521-290">

Because <link> is not valid as arbitrary body-flow content in all HTML contexts, implementations may instead use a neutral semantic element such as <meta> where permitted or an inert flow element such as <span>.

The recommended general-purpose representation inside WebMEM templates is:

<span
  data-webmem-relationship
  data-source-id="contract:H5521"
  data-predicate="hasPlan"
  data-target-id="plan:H5521-290">
</span>

The relationship semantics come from the attributes rather than the HTML element name.

`data-webmem-relationship`

data-webmem-relationship identifies an element as an explicit WebMEM relationship assertion.

It is a presence attribute.

`data-source-id`

data-source-id identifies the source object of a relationship.

Example:

data-source-id="contract:H5521"

This attribute identifies the source of the relationship, not an evidentiary data source.

Provenance uses data-provenance-ref.

The distinction is important:

relationship source
≠
provenance source

`data-predicate`

data-predicate identifies the semantic relationship being asserted.

Example:

data-predicate="hasPlan"

or:

data-predicate="availableIn"

or:

data-predicate="derivedFrom"

The predicate should be as precise as the publisher can support accurately.

`data-target-id`

data-target-id identifies the target object of a relationship.

Example:

data-target-id="plan:H5521-290"

The target may refer to an entity, fragment, dataset, term, resource, or other identifiable object appropriate to the relationship.

Relationship Scope

A relationship may carry its own applicability context.

Example:

<span
  data-webmem-relationship
  data-source-id="plan:H5521-290-0"
  data-predicate="availableIn"
  data-target-id="county:04015"
  data-plan-year="2026">
</span>

The relationship should not be interpreted as applying outside the stated plan year unless other context establishes that broader applicability.

Relationship Provenance

A relationship may reference provenance:

<span
  data-webmem-relationship
  data-source-id="plan:H5521-290-0"
  data-predicate="availableIn"
  data-target-id="county:04015"
  data-plan-year="2026"
  data-provenance-ref="#source-cms-landscape-2026">
</span>

This allows the publisher to establish not only the relationship but the evidentiary basis for asserting that relationship.

Read the Relationships specification →

Collections and Indexes

Collections should preserve both collection identity and member identity.

An IndexFragment may use ordinary list structures where order is not inherently meaningful.

Example:

<template
  data-webmem-fragment
  data-fragment-class="IndexFragment"
  data-fragment-id="mohave-county-plan-index"
  data-entity-id="county:04015">

  <ul data-webmem-collection data-collection-id="plans:county:04015:2026">

    <li data-member-id="plan:H5521-290-0">
      H5521-290-0
    </li>

    <li data-member-id="plan:H1234-001-0">
      H1234-001-0
    </li>

  </ul>

</template>

The list communicates collection membership.

The collection should not imply ranking unless ranking semantics are explicitly declared.

`data-webmem-collection`

data-webmem-collection identifies an element as a WebMEM collection structure.

Common HTML containers may include:

<ul> for unordered collections;
<ol> for semantically ordered collections;
<dl> for term-value or key-description structures;
<table> for tabular knowledge;
or another semantic HTML structure appropriate to the represented knowledge.

Collection Members

data-member-id identifies the entity or knowledge object participating as a member of a collection.

Example:

<li data-member-id="plan:H5521-290-0">
  H5521-290-0
</li>

A member may also contain additional structured attributes or relationships when required.

Ordered Structures

When order is semantically meaningful, HTML-in-HTML should use a structure with defined ordering semantics.

For example, ProcedureFragment steps may use:

<ol data-webmem-sequence>

  <li data-step-id="step-1">
    Gather required documents.
  </li>

  <li data-step-id="step-2">
    Complete the application.
  </li>

  <li data-step-id="step-3">
    Submit the application.
  </li>

</ol>

The order of the <li> elements is semantically meaningful because the containing structure declares a sequence.

By contrast, the physical order of independent fragment containers does not automatically create sequence semantics.

Structured Knowledge Beyond Scalar Assertions

Not every Fragment Class is primarily a collection of scalar factual assertions.

PolicyFragment, ProcedureFragment, EligibilityFragment, ExplainerFragment, PersonaFragment, RecommendationFragment, and other classes may require larger structured blocks.

HTML-in-HTML should use native semantic HTML where appropriate.

Examples include:

<section> for a semantic sub-block;
<dl> for term-definition or property-value structures;
<ol> for ordered procedures;
<ul> for unordered collections;
<table> for tabular relationships or comparisons;
<blockquote> where quoted source language is semantically appropriate;
and <data> for scalar values.

The Fragment Class and WebMEM attributes establish the machine semantics.

Example: PolicyFragment

<template
  data-webmem-fragment
  data-fragment-class="PolicyFragment"
  data-fragment-id="late-enrollment-penalty"
  data-entity-id="policy:late-enrollment-penalty">

  <section data-policy-rule>

    <h3>Late Enrollment Penalty</h3>

    <p data-rule>
      A penalty may apply when qualifying coverage is delayed
      beyond the permitted period.
    </p>

    <ul data-exceptions>
      <li data-exception-id="creditable-coverage">
        Creditable coverage may prevent the penalty.
      </li>
    </ul>

  </section>

</template>

The serialized structure represents policy knowledge rather than forcing the policy into scalar field-value pairs.

Example: ProcedureFragment

<template
  data-webmem-fragment
  data-fragment-class="ProcedureFragment"
  data-fragment-id="application-procedure"
  data-entity-id="procedure:program-application">

  <h3 data-task>Apply for the Program</h3>

  <ol data-webmem-sequence>

    <li data-step-id="step-1">
      Gather required documents.
    </li>

    <li data-step-id="step-2">
      Complete the application.
    </li>

    <li data-step-id="step-3">
      Submit the application.
    </li>

  </ol>

</template>

Example: EligibilityFragment

<template
  data-webmem-fragment
  data-fragment-class="EligibilityFragment"
  data-fragment-id="program-eligibility"
  data-entity-id="program:example">

  <section data-eligibility-criteria>

    <data
      data-webmem-assertion
      data-field="income_limit"
      value="2000"
      data-type="currency"
      data-unit="USD">
      $2,000
    </data>

    <data
      data-webmem-assertion
      data-field="residency_required"
      value="true"
      data-type="boolean">
      Residency required
    </data>

  </section>

</template>

Conditional logic may be represented through explicit semantic structures when necessary, but HTML-in-HTML does not imply executable code.

HTML-in-HTML Is Declarative

WebMEM HTML serialization is declarative.

It represents knowledge.

It does not execute code.

The presence of:

Policy
→ condition
→ outcome

or:

Eligibility
→ criteria
→ applicable procedure

does not require the browser or consuming machine to execute those structures automatically.

HTML-in-HTML is not an agent runtime, workflow engine, or executable rule system.

Internal References

A reference beginning with # may refer to an identifiable object within the same HTML document.

Example:

data-provenance-ref="#source-cms-pbp-2026"

The referenced object should have a corresponding HTML id or other unambiguous local identity mapping.

Example:

<template
  id="source-cms-pbp-2026"
  data-webmem-fragment
  data-fragment-class="MetaFragment"
  data-fragment-id="source-cms-pbp-2026"
  data-entity-id="dataset:cms-pbp-2026">

  ...

</template>

External References

External references should use stable URIs where available.

Example:

data-target-id="https://example.org/contracts/H5521/#entity"

or:

data-canonical-resource="https://example.org/contracts/H5521/"

External resource identity and entity identity should remain distinguishable.

Canonical Resources

A canonical-resource relationship may be represented explicitly:

<span
  data-webmem-relationship
  data-source-id="plan:H5521-290-0"
  data-predicate="canonicalResource"
  data-target-id="https://example.org/plans/H5521-290-0/">
</span>

or, where the containing identity context makes the source unambiguous:

<a
  data-webmem-relationship
  data-predicate="canonicalResource"
  data-target-id="https://example.org/plans/H5521-290-0/"
  href="https://example.org/plans/H5521-290-0/">
  Canonical Plan Resource
</a>

The hyperlink provides navigation.

The WebMEM attributes provide relationship semantics.

Context Inheritance

HTML-in-HTML uses containment as one mechanism for shared context.

Conceptually:

SDT Context
        ↓
Fragment Context
        ↓
Sub-Structure Context
        ↓
Assertion Context

A more specific declaration overrides a broader inherited declaration for the object on which it appears.

For example:

<template
  data-webmem-sdt
  data-plan-year="2026">

  <template
    data-webmem-fragment
    data-fragment-class="DataFragment"
    data-entity-id="plan:H5521-290-0"
    data-provenance-ref="#source-pbp">

    <data
      data-webmem-assertion
      data-field="monthly_premium"
      value="0"
      data-type="currency"
      data-unit="USD">
      $0
    </data>

    <data
      data-webmem-assertion
      data-field="enrollment"
      value="2136"
      data-type="integer"
      data-applicable-date="2026-07"
      data-provenance-ref="#source-enrollment">
      2,136
    </data>

  </template>

</template>

The enrollment assertion inherits plan identity and plan year but overrides the source provenance and adds a more specific applicable period.

Inheritance Rules

When resolving inherited context, a parser should use the nearest applicable declaration in the containment hierarchy.

Conceptually:

Assertion-specific value
        ↓ preferred over
Sub-structure value
        ↓ preferred over
Fragment value
        ↓ preferred over
SDT value

Inheritance must not be used to erase material semantic differences.

The nearest declaration wins only when the property is valid at that semantic level.

Unknown, Missing, and Not Applicable

HTML-in-HTML should distinguish among:

a value that is unknown;
a value that is missing from the publisher’s data;
a value that is not applicable;
and a value that is zero or false.

These states are not equivalent.

For example:

0
≠
false
≠
unknown
≠
not applicable
≠
missing

Where one of these states is material, the assertion should declare it explicitly.

Example:

<data
  data-webmem-assertion
  data-field="monthly_premium"
  data-state="not-applicable">
  Not applicable
</data>

A value attribute should not be fabricated merely to satisfy syntax when no actual value exists.

Unresolved Resolution State

HTML-in-HTML must be capable of preserving unresolved applicability when multiple materially different candidates remain.

For example:

<section
  data-webmem-resolution-state="unresolved"
  data-required-context="geography">

  <span data-candidate-id="segment:H5521-290-001"></span>
  <span data-candidate-id="segment:H5521-290-002"></span>

</section>

The serialization should not select one candidate merely because representing one value is simpler.

Material ambiguity must survive serialization.

HTML Escaping

All serialized HTML must remain valid HTML.

Attribute values must be escaped according to ordinary HTML rules.

For example, an ampersand appearing in an attribute value should be represented appropriately.

WebMEM does not define an alternate escaping model.

Character Encoding

WebMEM HTML serialization should use the character encoding declared by the containing HTML document.

UTF-8 is recommended for interoperable publication.

The serialization should not introduce an independent encoding layer inside the SDT.

DOM Validity

A conforming HTML-in-HTML representation must remain valid enough for ordinary HTML parsing to preserve the intended structure.

Malformed nesting, duplicate identifiers, broken attribute quoting, or invalid element placement can prevent reliable recovery of the WebMEM model.

The fact that the structure is inert does not remove the requirement for valid HTML parsing behavior.

Fragment Nesting

WebMEM fragment containers are direct or indirect descendants of the SDT container.

A fragment should not normally be nested inside another fragment as a substitute for explicit composition or relationships.

Preferred:

SDT
├── Fragment A
├── Fragment B
└── Fragment C

rather than:

SDT
└── Fragment A
    └── Fragment B

unless a future Fragment Class or serialization profile explicitly defines nested-fragment semantics.

Relationships among fragments should normally be represented through identity and relationship references.

Multiple Fragments About One Entity

An SDT may contain several fragments describing the same entity.

Example:

<template data-webmem-sdt ...>

  <template
    data-webmem-fragment
    data-fragment-class="IdentityFragment"
    data-fragment-id="plan-identity"
    data-entity-id="plan:H5521-290-0">
    ...
  </template>

  <template
    data-webmem-fragment
    data-fragment-class="DataFragment"
    data-fragment-id="plan-benefits"
    data-entity-id="plan:H5521-290-0">
    ...
  </template>

  <template
    data-webmem-fragment
    data-fragment-class="ExplainerFragment"
    data-fragment-id="plan-explainer"
    data-entity-id="plan:H5521-290-0">
    ...
  </template>

</template>

The shared entity identity establishes common subject identity.

The distinct fragment identities and Fragment Classes preserve different semantic roles.

Multiple Entities Within One SDT

An SDT may represent multiple related entities.

For example:

County
→ Plans
→ Contracts
→ Carriers
→ Formularies

Each entity must retain its own identity.

Participation in the same SDT does not make the entities equivalent.

Relationships should establish how those identities connect.

Full Example: County-Level SDT

<template
  data-webmem-sdt
  data-sdt-id="https://example.org/medicare-options/arizona/mohave-county/#webmem"
  data-geography-id="county:04015"
  data-plan-year="2026">

  <template
    id="source-cms-landscape-2026"
    data-webmem-fragment
    data-fragment-class="MetaFragment"
    data-fragment-id="source-cms-landscape-2026"
    data-entity-id="dataset:cms-landscape-2026">

    <data
      data-webmem-assertion
      data-field="title"
      value="CMS Medicare Advantage Landscape 2026"
      data-type="text">
      CMS Medicare Advantage Landscape 2026
    </data>

    <data
      data-webmem-assertion
      data-field="creator"
      value="Centers for Medicare & Medicaid Services"
      data-type="text">
      Centers for Medicare &amp; Medicaid Services
    </data>

  </template>


  <template
    data-webmem-fragment
    data-fragment-class="IdentityFragment"
    data-fragment-id="mohave-county-identity"
    data-entity-id="county:04015">

    <data
      data-webmem-assertion
      data-field="canonical_name"
      value="Mohave County"
      data-type="text">
      Mohave County
    </data>

    <data
      data-webmem-assertion
      data-field="state"
      value="AZ"
      data-type="identifier"
      data-identifier-system="usps-state">
      Arizona
    </data>

  </template>


  <template
    data-webmem-fragment
    data-fragment-class="IndexFragment"
    data-fragment-id="mohave-county-plan-index"
    data-entity-id="county:04015"
    data-provenance-ref="#source-cms-landscape-2026">

    <ul
      data-webmem-collection
      data-collection-id="plans:county:04015:2026">

      <li data-member-id="plan:H5521-290-0">
        H5521-290-0
      </li>

      <li data-member-id="plan:H1234-001-0">
        H1234-001-0
      </li>

    </ul>

  </template>


  <template
    data-webmem-fragment
    data-fragment-class="DerivedStatsFragment"
    data-fragment-id="mohave-county-derived-stats"
    data-entity-id="county:04015"
    data-provenance-ref="#source-cms-landscape-2026">

    <data
      data-webmem-assertion
      data-field="plan_count"
      value="42"
      data-type="integer"
      data-derived="true"
      data-method="count">
      42
    </data>

    <data
      data-webmem-assertion
      data-field="average_monthly_premium"
      value="15.26"
      data-type="currency"
      data-unit="USD"
      data-derived="true"
      data-method="arithmetic-mean">
      $15.26
    </data>

  </template>


  <span
    data-webmem-relationship
    data-source-id="county:04015"
    data-predicate="hasAvailablePlan"
    data-target-id="plan:H5521-290-0"
    data-plan-year="2026"
    data-provenance-ref="#source-cms-landscape-2026">
  </span>

</template>

Parsing Model

A conforming HTML-in-HTML parser should conceptually perform the following operations:

1. Parse the HTML document.

2. Locate <template> elements carrying data-webmem-sdt.

3. Read data-sdt-id and applicable SDT-level context.

4. Locate descendant WebMEM fragment containers.

5. For each fragment:
   - read fragment identity;
   - read Fragment Class;
   - resolve subject identity;
   - establish inherited context;
   - parse assertions and structures;
   - resolve provenance references;
   - parse relationships;
   - preserve applicability.

6. Preserve unresolved ambiguity where represented.

7. Recover the WebMEM conceptual model.

The parser does not need to render the template contents visually.

WebMEM does not prescribe how the recovered model must subsequently be indexed, stored, ranked, reasoned over, or displayed.

Parser Independence

A conforming representation should not depend on:

JavaScript execution;
CSS rendering;
screen position;
visual proximity;
browser interaction;
hidden runtime state;
or application-specific DOM mutation

to establish semantic meaning required by the WebMEM model.

The necessary structure should exist declaratively in the serialized HTML.

HTML-in-HTML and Human Content

The machine-facing SDT may repeat knowledge also represented in human-facing prose, tables, or interfaces.

This is expected under dual publishing.

The two representations should remain semantically aligned.

However, the machine-facing representation does not need to mirror the human-facing DOM structure.

For example, human content may use:

cards
tabs
tables
accordions
marketing copy
interactive filters

while the SDT organizes the same underlying knowledge through:

IdentityFragment
IndexFragment
DataFragment
DerivedStatsFragment
Relationships

Alignment requires consistent knowledge, not identical markup.

HTML-in-HTML and Dataset JSON-LD

Schema.org Dataset JSON-LD should remain outside the inert SDT container.

Recommended structure:

<head>

  <script type="application/ld+json">
  {
    "@context": "https://schema.org",
    "@type": "Dataset",
    "@id": "https://example.org/resource/#webmem",
    "url": "https://example.org/resource/"
  }
  </script>

</head>

<body>

  ...

  <template
    data-webmem-sdt
    data-sdt-id="https://example.org/resource/#webmem">

    ...

  </template>

</body>

Dataset JSON-LD is an external dataset declaration mechanism.

HTML-in-HTML is the serialization of the WebMEM knowledge model.

The shared identity maps the two.

HTML-in-HTML Is Not Microdata

WebMEM HTML-in-HTML should not be confused with Schema.org Microdata.

Microdata uses attributes such as:

itemscope
itemtype
itemprop

to annotate visible or document-associated content according to external vocabularies.

WebMEM uses inert HTML containers and WebMEM-specific semantic attributes to serialize the WebMEM knowledge model.

The two approaches may coexist on the same page but perform different functions.

HTML-in-HTML Is Not JSON-LD

HTML-in-HTML does not encode the WebMEM model as a JSON document inside HTML.

The serialized structure remains HTML.

Conceptually:

HTML parser
→ DOM
→ WebMEM model

rather than:

HTML parser
→ embedded JSON text
→ JSON parser
→ WebMEM model

HTML-in-HTML Is Not YAML-in-HTML

WebMEM 1.x used YAML text embedded within HTML <template> elements.

That representation typically required:

HTML
→ locate template
→ extract text
→ parse YAML
→ interpret WebMEM

The current serialization returns WebMEM to a native-HTML structure:

HTML
→ parse DOM
→ interpret WebMEM

The change removes YAML as an intermediate syntax layer.

It does not remove the Semantic Data Template, Fragment Classes, provenance, identity, relationships, or other durable concepts of the WebMEM architecture.

The current HTML-in-HTML serialization returns WebMEM to its original native-HTML design principle while preserving the more mature conceptual architecture now defined by the protocol.

Relationship to the Original WebMEM Design

The original WebMEM design used non-rendered HTML containers and structured data-* attributes to bind machine-readable meaning, identity, values, provenance, glossary alignment, and other semantics directly to knowledge represented within web content.

The current serialization preserves that underlying design principle.

The principal architectural change is separation of concerns:

Original Design

HTML Container
+
Semantic Data Bindings
+
Fragment Knowledge


Current Protocol

WebMEM Conceptual Model
        ↓
Serialization Contract
        ↓
HTML-in-HTML
        ↓
<template> + semantic HTML + data-* bindings

The present specification therefore modernizes the HTML representation without treating earlier YAML-specific, digest-specific, retrieval-specific, trust-scoring, or memory-conditioning mechanisms as requirements of the current knowledge model.

Reserved WebMEM Attributes

The following attribute families are reserved by the current HTML-in-HTML serialization:

data-webmem-*
data-sdt-*
data-fragment-*
data-entity-*
data-provenance-*
data-defined-term-*
data-relationship-*
data-collection-*
data-member-*
data-resolution-*

Domain implementations may define additional data-* attributes where needed, provided those attributes do not conflict with reserved WebMEM semantics.

Domain-specific extensions should not redefine the meaning of reserved WebMEM attributes.

Extensibility

HTML-in-HTML is designed to allow domain-specific extension without requiring every possible domain field to become part of the WebMEM core vocabulary.

For example, a healthcare implementation may introduce:

data-plan-year
data-contract-id
data-plan-id
data-segment-id

while an automotive implementation may introduce:

data-model-year
data-vin
data-engine-code

Such attributes provide domain context.

They do not replace core WebMEM semantics such as entity identity, provenance, relationships, Fragment Class, or SDT identity.

Validation

A validator for HTML-in-HTML should evaluate both structural HTML requirements and WebMEM semantic requirements.

Structural validation may include:

valid SDT container;
stable SDT identity;
valid fragment containers;
unique fragment identifiers;
recognized Fragment Classes;
well-formed attributes;
resolvable internal references;
and valid nesting.

Semantic validation may include:

required subject identity;
datatype/value compatibility;
required unit information;
provenance availability;
derived/source-observed distinction;
relationship source/predicate/target completeness;
applicability scope;
identity boundary preservation;
and Fragment Class-specific conformance.

Malformed Structures

A representation should be considered malformed or non-conforming when necessary semantic structure cannot be recovered reliably.

Examples include:

an SDT container without an identifiable SDT;
a fragment without a Fragment Class;
duplicate fragment IDs within the same SDT;
an assertion whose value cannot be interpreted according to its declared datatype;
a provenance reference that cannot be resolved;
a relationship missing a source, predicate, or target where those values are not inherited unambiguously;
an entity identifier whose scope is materially ambiguous;
or invalid HTML nesting that changes the intended DOM structure.

Serialization Failure Modes

Common HTML-in-HTML serialization failures include:

SDT / Fragment Collapse

A fragment is treated as though it were the page-level SDT.

Fragment Class Loss

The fragment exists but does not preserve what kind of knowledge it represents.

Identity Loss

A value remains present but the entity to which it applies becomes ambiguous.

Provenance Loss

The source or derivation lineage is removed during serialization.

Relationship Flattening

Related entities remain listed but the predicates explaining their connections disappear.

Applicability Collapse

Geographic, temporal, segment-level, jurisdictional, or other conditions required to interpret knowledge correctly are omitted.

Inheritance Leakage

Context declared at one level incorrectly propagates into knowledge for which it is not valid.

Presentation Dependence

Meaning depends on CSS layout, visual proximity, or human interpretation rather than explicit machine-facing structure.

False Resolution

Multiple candidates remain applicable, but serialization exposes one as uniquely resolved.

Syntax Conflation

An implementation assumes that a particular HTML element defines the WebMEM concept rather than serializing it.

Conformance

A conforming HTML-in-HTML serialization must:

represent the page-level SDT using an inert HTML <template> carrying data-webmem-sdt;
provide an identifiable data-sdt-id;
represent WebMEM fragments within the SDT using fragment containers carrying data-webmem-fragment;
identify each fragment’s Fragment Class;
provide fragment identity sufficient to distinguish fragments within the applicable SDT;
preserve subject identity where required by the knowledge;
preserve assertions and structures appropriate to the declared Fragment Class;
preserve machine values, datatypes, and units where material;
preserve source-observed versus derived distinctions;
preserve provenance or provenance references where required;
preserve relationship source, predicate, and target semantics;
preserve geographic, temporal, jurisdictional, population, segment-level, or other applicability context when material;
preserve semantically meaningful ordering;
preserve identity boundaries among SDTs, fragments, entities, datasets, and resources;
preserve unresolved ambiguity where the knowledge model remains unresolved;
provide unambiguous internal references;
remain parseable using ordinary HTML parsing without requiring JavaScript execution;
and preserve the semantic meaning required by the WebMEM serialization contract.

A representation that is valid HTML but materially changes or omits the semantics of the WebMEM knowledge model is not a conforming WebMEM HTML serialization.

Relationship to WebMEM 1.x

WebMEM 1.x used the HTML <template> element as an inert publication container but commonly embedded YAML text inside that container.

Earlier implementations also used attributes and fields such as:

data-entity
data-fragment-id
data-source
data-glossary
data-confidence
data-derived
data-provenance
data-digest
data-fragment-scope

Many of the underlying semantic concerns remain important.

The current HTML-in-HTML serialization reorganizes those concerns around the current WebMEM architecture:

SDT
→ page-level machine knowledge representation

Fragment
→ modular semantic knowledge object

Fragment Class
→ semantic role

Assertion / Structure
→ publisher knowledge

Identity
→ subject

Provenance
→ lineage

Relationships
→ connective structure

Resolution
→ applicability

Earlier retrieval hints, trust scores, semantic-digest requirements, memory-conditioning assumptions, and multi-format endpoint requirements are not required by the current HTML serialization unless separately defined by an applicable profile.

The original native-HTML binding principle remains:

WebMEM knowledge is embedded directly into ordinary web content using inert HTML containers and machine-readable semantic bindings without requiring visible rendering or client-side execution.

HTML-in-HTML and Protocol Integrity

HTML-in-HTML is the boundary where the WebMEM conceptual model becomes an actual published artifact.

The specification therefore has one overriding responsibility:

Carry the knowledge model into HTML without losing the distinctions that make the knowledge interpretable.

Conceptually:

Identity
→ must survive serialization

Provenance
→ must survive serialization

Fragment Class
→ must survive serialization

Assertions
→ must survive serialization

Relationships
→ must survive serialization

Applicability
→ must survive serialization

Ambiguity
→ must survive serialization

Resolution structure
→ must survive serialization

If the values survive but those semantic distinctions disappear, the serialization has preserved data while losing knowledge.

HTML-in-HTML exists to prevent that collapse.

Overview

Design Principle

Why <template>

HTML-in-HTML Document Structure

The SDT Container

data-webmem-sdt

data-sdt-id

Page-Level Context

Fragment Containers

data-webmem-fragment

data-fragment-class

data-fragment-id

data-entity-id

Fragment-Level Context

Assertions

data-webmem-assertion

data-field

Assertion Values

Datatypes

Boolean Values

Dates and DateTimes

Currency

Percentages

Identifiers as Values

Enumerated Values

Units

Descriptions

Defined Terms

Assertion-Specific Identity

Derived Assertions

Provenance References

Provenance Inheritance

Relationships

data-webmem-relationship

data-source-id

data-predicate

data-target-id

Relationship Scope

Relationship Provenance

Collections and Indexes

data-webmem-collection

Collection Members

Ordered Structures

Structured Knowledge Beyond Scalar Assertions

Example: PolicyFragment

Example: ProcedureFragment

Example: EligibilityFragment

HTML-in-HTML Is Declarative

Internal References

External References

Canonical Resources

Context Inheritance

Inheritance Rules

Unknown, Missing, and Not Applicable

Unresolved Resolution State

HTML Escaping

Character Encoding

DOM Validity

Fragment Nesting

Multiple Fragments About One Entity

Multiple Entities Within One SDT

Full Example: County-Level SDT

Parsing Model

Parser Independence

HTML-in-HTML and Human Content

HTML-in-HTML and Dataset JSON-LD

HTML-in-HTML Is Not Microdata

HTML-in-HTML Is Not JSON-LD

HTML-in-HTML Is Not YAML-in-HTML

Relationship to the Original WebMEM Design

Reserved WebMEM Attributes

Extensibility

Validation

Malformed Structures

Serialization Failure Modes

SDT / Fragment Collapse

Fragment Class Loss

Identity Loss

Provenance Loss

Relationship Flattening

Why `<template>`

`data-webmem-sdt`

`data-sdt-id`

`data-webmem-fragment`

`data-fragment-class`

`data-fragment-id`

`data-entity-id`

`data-webmem-assertion`

`data-field`

`data-webmem-relationship`

`data-source-id`

`data-predicate`

`data-target-id`

`data-webmem-collection`