What you describe lies outside the capabilities of XSD 1.0 or 1.1
key/keyref constraints: they can check that a given value which occurs in
the document as a keyref also occurs in the document as a key, but
functions like substring-before and substring-after are not available in
XSD identity constraints.
If the value_source attribute were split into two attributes, you'd have
no particular problem using identity constraints to solve your problem.
Given the XML structure you've got, however, if you're in XSD 1.1 your only
realistic option is to use assertions to impose the constraints you have in
[Addition] You don't say where document keeps the key values to which
the parts of the value_source attribute value must correspond, so a
complete working example will necessarily be a bit of a work of fiction.
But let us assume that
param elements can occur anywhere in
the document, and the individual dot-delimited parts of their @source_value
attribute must match the @id value on a
occurring as a child of
value_sources, which in turn occurs as
a child of
other-stuff, which it itself a child of the root
In the declaration of the complex type used on the root element, then,
you'd add an assertion of something like the following form:
every $param in .//param
(every $sourceref in tokenize($param/@value_source,'.')
(some $sourcedecl in ./other-stuff/value_sources/source
($sourcedecl/@id = $sourceref)))
The key point to remember is that XSD 1.1 assertions can only point
downward, into the element whose type contains the assertions. So you
can't put the assertion on the
param element. You have to put
it on some element which is guaranteed to contain both the
param element and the elements or attributes whose values the
param/@value_source is constrained to match. If, as you say,
you know how to write the key constraints for the case where the
value_source doesn't have to be tokenized, then you should have no problem
figuring out how to point to the relevant values here.
Note, however, that XSD 1.1 implementations are not required to support
all of XPath 2.0 in assertions; they are allowed to support only a smaller
subset of XPath. Saxon and Xerces, however, both seem to handle the
assertion given above without trouble.