1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
//! External resource resolution for `<include href="...">` (issue #2).
//!
//! This crate never reads files or the network itself — `Cargo.toml`/
//! `CLAUDE.md`'s "no host-format/I/O dependency in the core" policy
//! applies here too. A caller who wants `<include>` support implements
//! [`SchemaResolver`] over whatever loading mechanism (files, an
//! in-memory map, HTTP, ...) fits, with whatever security boundary
//! (allowed schemes, path restrictions) is appropriate there, and calls
//! [`crate::parse_with_resolver`] instead of [`crate::parse`]. Mirrors the
//! sister crate `relax-ng`'s `SchemaResolver`/`SchemaSource` shape (same
//! problem — external `href` resolution without owning I/O — same shape).
//!
//! `<extends href="...">` (external-file rule reuse, the other half of
//! issue #2) is *not* wired up to this trait yet — the ISO reference
//! implementation (`iso_dsdl_include.xsl`) itself labels `extends[@href]`
//! "experimental and non-standard", with different substitution semantics
//! than `<include>` (it splices the target element's *children*, not the
//! element itself, and shares `<include>`'s own `#fragment-id` lookup
//! complexity). Deferred rather than rushed — see `README.md`'s support
//! matrix.
use fmt;
/// Schema text plus the base URI relative `href`s inside it resolve
/// against.
/// Resolves an `<include href="...">` `href` (relative to a base URI) to
/// the [`SchemaSource`] it names. This crate has no file-system or network
/// access of its own — implement this over whatever loading mechanism
/// fits the caller.
/// A [`SchemaResolver`] failed to resolve an `href`.