A Relative URL reference identifies a target using a base URL to supply missing context. It can contain a path, a query string or a fragment identifier, without independently specifying an entire network address. Resolution combines the reference with the base according to a defined algorithm.^[ref]

Trailing slashes provide an illuminating comparison. Resolving c against https://example.org/a/b gives https://example.org/a/c; resolving it against https://example.org/a/b/ gives https://example.org/a/b/c. In the first case the last base path segment is replaced, while in the second it names a directory-like prefix.

A parent-directory step is similarly concrete: ../image.png against https://example.org/a/b/page.html gives https://example.org/a/image.png. These outcomes follow from URL processing, not from examining an actual filesystem. No network request is needed to calculate them.^[ref]

The base is therefore part of the input. Copying the same relative spelling into a document with a different base can change its target even when every character of the reference stays unchanged.

A query string is the component following ? and preceding #, or the end, in a URL. It carries data whose interpretation is defined by the resource or application. The generic syntax does not require a dictionary of names and values.^[ref]

For example, https://example.org/search?q=red&tag=a&tag=b#results has query q=red&tag=a&tag=b. An application using form-style conventions can interpret repeated tag entries as a list. URLSearchParams preserves repeated entries: getAll('tag') returns both a and b. Converting that list directly into a dictionary with one value per name can lose information.

Encoding conventions also matter. Under URLSearchParams parsing, q=a+b gives the value a b, while q=a%2Bb gives a+b. That distinction comes from the specified form parser, rather than a general law that every plus in every URL means a space.^[ref]

A useful test records both the original query string and the parsing convention. A changed spelling, changed list of values and changed server response are three different observations.

A fragment identifier is the component introduced by # in a URL, supplying a reference within or associated with the identified resource. In https://example.org/manual.html#setup, setup is the fragment. Interpretation depends on the representation and its rules; an HTML element identifier is a familiar example, not the only possible meaning.^[ref]

The Hypertext Transfer Protocol target excludes the fragment. A browser requesting the preceding example requests the document without #setup, then can process the fragment locally. This differs from a query string, which can help identify the requested resource.^[ref]

For an illustrative comparison, manual.html#setup and manual.html#examples can select different places in one retrieved document. Changing only the fragment therefore need not imply fetching two different document bodies. Conversely, a syntactically valid fragment does not prove that a matching destination exists in the current document.

Percent-encoding represents a byte using a percent sign followed by two hexadecimal digits. For example, byte value 32 is written %20. Non-ASCII text is first encoded as bytes: in UTF-8, é becomes the two bytes hexadecimal C3 A9, represented as %C3%A9.^[ref]

A useful example distinguishes data from delimiters. The path in https://example.org/a/b has two segments; the path in https://example.org/a%2Fb retains the encoded slash within one segment in the parsed URL record. A server may apply additional decoding, but the two spellings must not be assumed interchangeable at every processing stage.

Percent-encoding is neither encryption nor a universal instruction to decode repeatedly. The string %252F decodes once to the text %2F; a second decoding changes it again. Likewise, the plus sign is not universally a space: that convention belongs to form-style query string processing, including URLSearchParams, rather than all URL components.^[ref]

URL serialization produces the textual spelling of a structured URL record. It is the output side of processing that begins with a URL parser. The WHATWG serializer returns an ASCII string and can optionally omit the fragment identifier.^[ref]

A worked example separates the stages. Constructing new URL('https://EXAMPLE.org:443/a/../b?q=hello%20world~#top') gives href equal to https://example.org/b?q=hello%20world~#top. Lowercasing the host, removing the default port and resolving the parent-directory segment happen during parsing; the serializer exposes the resulting record.

Now call u.searchParams.sort() on that object. Even though there is only one query pair to sort, href becomes https://example.org/b?q=hello+world%7E#top. The decoded query value is unchanged, but URLSearchParams has rewritten its spelling using form URL encoding. Thus changing the query through an API can alter its percent-encoding without changing the value returned by that API.^[ref]

A serialized address is also different from a browser's chosen display text or a server's returned content. Comparing those different outputs answers different questions.

A URL record is the structured internal representation of a URL, rather than its original text. The URL parser produces components such as scheme, host, port, path, query string and fragment identifier; URL serialization turns the record into a string. A component can be absent, and the representation of a path depends on the scheme.^[ref]

Parse https://example.org:8443/a?x=1#part. The host is example.org, the port is 8443, the path contains a, the query is x=1, and the fragment is part. The separators ? and # belong to the serialized syntax, rather than the stored query and fragment values. These fields let a program change one component without guessing its boundaries by cutting an arbitrary string.

The original spelling need not survive. Parsing https://EXAMPLE.org:443/a yields a lowercased host and no stored explicit port, because 443 is the scheme default. Therefore the record does not contain a faithful log of every character supplied by the user. If an application needs that log, it must retain the input separately.^[ref]

Urate denotes an anion obtained by removing one or more protons from uric acid; the charge state should be specified when needed. The commonly discussed monoanion has formula ${\mathrm{C}}_5{\mathrm{H}}_3{\mathrm{N}}_4{\mathrm{O}}_3^{-}$, whereas neutral uric acid has one additional hydrogen. A urate salt includes charge-balancing cations as well as the urate ion.^[ref]

Writing neutral uric acid as ${\mathrm{H}}_2\mathrm{U}$ and its monoanion as $\mathrm{H}{\mathrm{U}}^{-}$ gives the acid–base equilibriumThis changes protonation and charge without changing the carbon, nitrogen or oxygen framework. In a simplified mixture containing only these two forms, a concentration ratio $[\mathrm{H}{\mathrm{U}}^{-}]/[{\mathrm{H}}_2\mathrm{U}]=4$ means that four fifths of their combined amount is monoanion. A total of1millimole would then comprise0.8millimole monoanion and0.2millimole neutral acid; the ratio alone does not specify the total amount.

The formation of urate in purine metabolism is a separate chemical transformation: xanthine dehydrogenase oxidizes xanthine toward the uric-acid/urate product family. That reaction changes the oxidation state and oxygen content, whereas the equilibrium above describes loss or gain of a proton after a particular framework has been specified.^[ref]

The physical Church-Turing principle asserts that a universal physical computing machine can simulate every finitely realizable physical system. It is a claim about physical laws and possible apparatus, stronger in subject matter than a mathematical account of effective symbolic calculation. Its exact force depends on what simulation accuracy and resource use are required.

David Deutsch's 1985 paper formulated a strong version in terms of perfect simulation by finite means and investigated a universal quantum model.^[ref] For example, describing one qubit requires specifying its quantum state and predicting quantum measurement probabilities; copying a short list of observed outcomes does not simulate all its permitted subsequent operations. Approximation to a chosen accuracy and efficient simulation are further, distinct requirements. The principle motivates universal quantum computation without itself being an experimental proof of every proposed universality claim.

A unit of force specifies the reference magnitude used to express a force. The SI derived unit is the newton, defined by $1\mathrm{N}=1\mathrm{kg}\mathrm{m}{\mathrm{s}}^{-2}$, consistent with Newton's second law.

A force of one newton gives a one-kilogram body an acceleration of one metre per second squared when it is the net applied force. A kilogram is a unit of mass, so it cannot replace the newton without also specifying an acceleration or a conventional gravitational reference.^[ref]

A unifier of first-order terms $s,t$ is a first-order substitution $\sigma$ for which $s\sigma =t\sigma$. The first-order substitution replaces variables by first-order terms; it does not alter function symbols. For example, $\{x\mapsto a,y\mapsto b\}$ unifies $f(x,g(y))$ with $f(a,g(b))$.

A most general unifier leaves every identification not forced by the original equations available for later choice. For $f(x,y)=f(y,z)$, one solution is $\{x\mapsto z,y\mapsto z\}$. The remaining variable $z$ is free. Replacing it by any finite first-order term gives a more specific unifier; arbitrarily choosing $z=a$ during the initial computation would discard that generality.

Not every pair is unifiable. Distinct constant symbols cannot be made equal by replacing variables, and the occurs check rejects $x=f(x)$ for finite first-order terms. These are structural restrictions, not numerical inequalities. Unifiers allow a resolution step to align the relevant atomic formulas before the logical inference is performed.^[ref]

Equational unification asks for a first-order substitution making two first-order terms equal under specified identities, rather than requiring them to become literally the same first-order term. Writing ${=}_E$ for equality justified by those identities, a solution $\sigma$ satisfies $s\sigma {=}_{E}t\sigma$.

For example, the first-order terms $f(a,b)$ and $f(b,a)$ have no syntactic unifier when $a,b$ are distinct constant symbols and $f$ is an uninterpreted binary function symbol. If the specified identity is commutativity, $f(x,y)=f(y,x)$, then the unchanged first-order terms are already equal modulo that identity: the empty first-order substitution is an equational unifier.

The identity set changes the problem. Ordinary first-order unification can decompose equal outer constructors because equality of free first-order terms forces equality of corresponding arguments. Modulo commutativity, argument positions can be exchanged, so that decomposition alone would reject legitimate solutions. A useful implementation must state its identities and its notion of solution, rather than treating equality of interpreted values as syntactic equality.

Canonical equivalence relates Unicode sequences that represent the same abstract text through canonically interchangeable representations. A precomposed character and its canonical decomposition are an important example. Unicode normalization makes canonically equivalent sequences share a specified normal form.^[ref]

The single code point U+00E9 and the pair U+0065 U+0301 differ in length and stored code units, but represent canonically equivalent accented text. NFD maps both to the decomposed pair, while NFC maps both to the composed character. Comparing raw bytes would miss that relationship if the representations differ. In contrast, the circled digit U+2460 and ordinary 1 have compatibility equivalence without canonical equivalence. Canonical normalization thus preserves more distinctions than the compatibility forms.

Compatibility equivalence relates Unicode sequences whose compatibility decompositions agree, including distinctions that may matter in some contexts. It includes canonical matches but can additionally identify characters differing in formatting or conventional presentation. Unicode normalization forms NFKD and NFKC use these broader decompositions.^[ref]

For example, the circled digit U+2460 and ordinary digit U+0031 both normalize to 1 under NFKC. NFC retains their distinction. A circled list marker and an ordinary numeral can therefore become indistinguishable under compatibility normalization, even when an application wanted to preserve the original notation. The choice is a representation policy, not a test of visual similarity: applying compatibility normalization requires deciding which distinctions the task may safely discard.

Logical text order is the order in which text characters are represented in a stored sequence for interpretation. A bidirectional renderer derives visual text order from that sequence; it does not require the stored characters to be prearranged in screen-position order.^[ref]

An original indexing example uses six abstract items. Write the stored positions in order asThe $R_i$ labels each stand for a single right-to-left text character. All displayed arrays here are read physically from left to right. Applying level-based reordering of bidirectional text to these supplied levels gives the visual list $a,R_2,1,2,R_1,b$, whose source-position list is $0,4,2,3,1,5$. Stored position1 remains position1 even though its item is drawn near the right end.

This distinction makes a text-processing task precise. An operation on logical positions1 through4 selects the contiguous stored subsequence $R_1,1,2,R_2$. A renderer may need a position map to relate that range to its displayed cells. Sorting characters by screen coordinate before searching or serializing the text would change the sequence being processed.

Logical order does not determine a font's glyph geometry. Text shaping, line layout and the Unicode Bidirectional Algorithm contribute different information. For example, a different line break can change which items are reordered together while the underlying stored sequence remains the same.^[ref]

Visual text order is the ordering of displayed text items within a rendered line. In bidirectional text it can differ from logical text order, the stored character sequence. It describes a presentation result, so the line boundaries and resolved directional information belong to its context.^[ref]

For an original permutation example, take six logical items $a,R_1,1,2,R_2,b$ with supplied levels $0,1,2,2,1,0$. The resulting left-to-right display positions contain source indicesThus the displayed items are $a,R_2,1,2,R_1,b$. The digits keep their internal order even though the surrounding right-to-left items exchange physical positions. A single reversal of the whole stored list would give a different result.

A position map preserves information that a picture alone may lose. If two source items both display as the same letter, their appearances do not reveal which logical index each came from. A renderer can retain distinct indices while drawing identical shapes. Likewise, interpreting a pointer position as a text location requires more information than simply treating a visual column number as a logical index.

The Unicode Bidirectional Algorithm orders text items, while text shaping determines additional glyph forms and combinations. Distinguishing these stages prevents a permutation of character positions from being mistaken for a complete specification of glyph geometry.^[ref]

Visual order is therefore useful for describing what appears on a particular line, while logical text order supplies stable positions for the represented sequence. Reporting both orders and their mapping makes an example reproducible without assuming that the reader's own browser will display a mixed-direction string in the intended way.

A Unicode bidirectional class is a character property, formally named Bidi_Class, used as input to the Unicode Bidirectional Algorithm. It classifies directional behavior; the algorithm combines the properties with context to compute bidirectional embedding levels. A class is not itself a final screen position.^[ref]

For a compact example, Latin A (U+0041) has classL, Hebrew alef (U+05D0) has classR, digit1 (U+0031) has classEN, and ordinary space (U+0020) has classWS. These labels distinguish strong directions, a numeric class and whitespace. They carry information that a single left-to-right/right-to-left Boolean would lose.

An original data-structure example keeps the stages separate. Represent each stored item by a record containing its logical index, code point, original Bidi_Class, working directional type, resolved level and eventual visual index. A direction-resolution step can update the working fields while leaving the stored code point and original property intact. A later level-based reordering of bidirectional text step changes position mappings rather than assigning new code points.

The advantage appears in debugging a digit within mixed-direction text. Its original classEN identifies a numeric input. Its resolved level describes the computed directional context, and its visual index identifies a placement in one line. Reporting only the visual index would conceal whether a mistake arose during classification, context resolution or final reordering.

The normative property data are supplied by the Unicode character database; broad descriptions such as “a letter in this script” have exceptions. An implementation should use the data for its chosen Unicode version rather than infer every character's class from appearance.^[ref]

A bidirectional embedding level is a nonnegative integer used by the Unicode Bidirectional Algorithm to represent directional nesting. A level whose value is an even integer has left-to-right embedding direction; one whose value is an odd integer has right-to-left embedding direction.^[ref]

Level values carry more information than parity. For example, levels2 and4 share the same default direction, but they participate differently in level-based reordering of bidirectional text. Higher values indicate more deeply nested directional structure, rather than a greater physical displacement across the screen.

An original supplied-level example uses the listThe level4 pass reverses $u,v$. The level3 pass reverses that same pair again, the level2 pass reverses it a third time, and the level1 pass reverses the larger middle run. The final physical left-to-right list is $a,R_2,u,v,R_1,b$. If the intermediate level3 pass were omitted merely because no item had level3, the middle pair would come out in the opposite order.

These are supplied resolved levels for an algebraic illustration, not a claim that arbitrary level arrays arise from any particular unformatted string. Resolving levels from Unicode bidirectional classes, explicit controls and context is an earlier part of the algorithm. The final reversal stage consumes those results.^[ref]

A level also differs from a character's original property. A decimal digit can be assigned a level within a surrounding directional context without becoming a different stored code point. Keeping the property, the computed level and the eventual display position separate makes implementation traces easier to check.

A bidirectional isolate is a span treated as a directional unit by the Unicode Bidirectional Algorithm. Its internal text is resolved separately from the surrounding text; the isolate as a whole behaves neutrally in its surroundings. This limits directional interaction when inserting a span whose contents have their own writing direction.^[ref]

Unicode directional controls can delimit the span: LRI (U+2066) chooses left-to-right isolation, RLI (U+2067) chooses right-to-left isolation, FSI (U+2068) infers direction from the first relevant strong character, and PDI (U+2069) terminates the isolate. Higher-level markup can express equivalent isolation without storing those explicit control characters.^[ref]

An original record-layout example has three fields: a fixed prefix, a user-supplied name and a fixed suffix containing punctuation and an identifier. Treat the inserted name as one isolated span. The outer layout then works with that span as a unit, while its contents receive their own directional processing. A name containing both letters and digits still needs internal reordering; isolation does not prescribe a reversal of every character inside it.

For a reproducible plain-text notation, write the sequence as prefix RLI payload PDI suffix, with the uppercase labels standing for control code points rather than literal letters in the displayed text. This notation documents the boundary without hiding directional controls in the source example. An actual test should record the concrete payload, paragraph direction, Unicode version and line boundaries as well.

Nesting introduces another distinction: a first-strong isolate determines its direction from an eligible strong character outside nested isolates. A direction already enclosed in a nested span need not choose the enclosing span's direction. Naming the span boundary and the rule used to choose its direction makes this behavior explicit.^[ref]

Level-based reordering of bidirectional text is the final positional reversal procedure of the Unicode Bidirectional Algorithm after directional levels and line boundaries have been resolved. RuleL2 processes thresholds from the largest level down through the smallest level whose value is an odd integer. Each pass reverses every maximal consecutive run whose levels meet or exceed the threshold.^[ref]

An original trace supplies the resolved levels rather than attempting to infer them. Take the logical itemsAt threshold2, reverse only the two middle digits, obtaining $(a,R_1,R_2,2,1,R_3,b)$. At threshold1, reverse the entire middle five-item run, givingThe digits underwent two reversals, preserving their internal order. The $R_i$ labels each denote one abstract right-to-left text character; every array is written in physical left-to-right order.

Thresholds include intermediate values that no item happens to have. For example, a pair at level4 surrounded by level1 items participates in passes4,3,2 and then the enclosing pass1. Omitting pass3 changes the result, as the bidirectional embedding level example demonstrates.

An implementation may carry levels with the items, as the figure generator does. It can also locate each reversal range from the original fixed level array: earlier passes permute items only inside higher-level runs, preserving the boundaries of every later lower-threshold run. Keeping logical indices on the displayed items supplies the eventual position map. Line-final whitespace resetting belongs to ruleL1, and combining-mark handling and mirroring require their separate rules.^[ref]

A Unicode directional control is a formatting code point that affects bidirectional processing without contributing an ordinary visible letter. Directional marks, embeddings, overrides and isolate delimiters provide different mechanisms within the Unicode Bidirectional Algorithm. They affect interpretation of the stored sequence rather than supplying new letter shapes.^[ref]

Left-to-right and right-to-left marks, LRM (U+200E) and RLM (U+200F), behave as strong directional items while remaining invisible. A right-to-left isolate initiator, RLI (U+2067), instead starts a bounded bidirectional isolate; PDI (U+2069) terminates it. A mark and a span delimiter therefore carry different structural information.^[ref]

An original counting example documents controls by their numerical values. The sequence U+2066 U+0061 U+0062 U+2069 contains LRI, the two Latin letters a and b, and PDI. It contains four code points and eight UTF-8 bytes: three for each delimiter and one for each Latin letter. Its ordinary visible letters are just a and b. Counting visible letters would therefore lose information about the represented sequence.

This notation intentionally shows the control values instead of placing hidden directional formatting characters in the source example. To reproduce an actual layout test, record its logical text order, paragraph direction, Unicode version and line boundaries, then compare the computed bidirectional embedding levels and visual text order.

A higher-level format can express equivalent directional structure through markup. The control-code-point representation and the markup representation need not have the same stored characters even when they request corresponding layout behavior. The specification defines those correspondences, while text shaping remains a further part of rendering.^[ref]