Function parse_with_resolver 

pub fn parse_with_resolver(
    xml: &str,
    base_uri: &str,
    resolver: &impl SchemaResolver,
) -> Result<Schema, ParseError>

Parses a Schematron .sch XML document into a Schema, first resolving every <include href="..."> in it (issue #2) via resolver — unlike parse, which treats <include> as an unsupported, unexpected element (ParseError::UnexpectedElement), same as a typo.

base_uri is the base URI xml’s own top-level hrefs resolve against (this crate has no notion of “the schema’s own file path” — it never reads files itself, see crate::SchemaResolver — so the caller supplies it, exactly mirroring crate::SchemaSource::new’s own base_uri parameter for nested includes).

Resolution is a pure text-substitution pass (resolve_includes) that runs before any structural parsing: every <include href="..."> is replaced, in place, by the XML text of its resolved root element, recursively (an included fragment’s own <include>s are resolved too, against its own base URI) — then the fully-expanded text is parsed exactly like a parse call, so every existing structural check (validate_known_children and friends) still applies to the expanded result: an included fragment of the wrong kind for where it was included (e.g. a whole <pattern> included at rule level, where only assert/report/extends/p belong) still surfaces as the same ParseError::UnexpectedElement it would if it had been written inline.

Only the common, unambiguous form is supported: href with no #fragment-id, resolving to a single Schematron-namespace root element (anything else — a non-Schematron-namespace root, or a whole <schema> — is ParseError::InvalidInclude). The ISO reference implementation’s #fragment-id cross-document lookup form (iso_dsdl_include.xsl) is not implemented — deferred, not silently mishandled: an href containing # is resolved as a literal, almost-certainly-nonexistent resource name and surfaces as ParseError::UnresolvableInclude via the caller’s own SchemaResolver, not silently ignored.