[dsdl-discuss] Re: Potential use cases for complex value validation from ebXML

From: "Martin Bryan" <mtbryan@sgml.u-net.com>

> The question comes as to whether an enumeration is actually a datatype, or
> whether it sits in a different validation phase.

That is an interesting point. Are you saying that an enumeration is
really a kind of link (whose other end may not be well defined)?

> So you need a mechanism where a
> local enumeration list includes an externally defined one. You also need to
> be able to subset enumeration lists. The example I am forever quoting here
> is the need to identify the current list of members in the European Union
> using ISO 3166 codes. At present we have some additional countries that have
> some or all of the EU rights while the bid for accession. Therefore for
> certain applications at the European Commission they need to validate
> whether the country code is a) a valid EU country b) a currently
> acknowledged accession country c) a country, like Switzerland, that has
> neither status but has special arrangements within the field under study
> (e.g. within IST research projects). So we need to include a subset of ISO
> 3166 and add two lists that are maintained independently but derived from
> ISO 3166 to this subset to create our enumeration, without having to define
> any entries per se as all are "standardized country identifiers".

I think all this can be done using Schematron and the document() function,
but I hesitate to recommend it because Schematron is a particularly good tool for the job
because typical implementations of XSLT's error handling (if an external resource
is not available) are slack.

With the document function, you could maintain a separate list

<countries>
  <county
    validEuCountry="no"
    acknowledgedAccessionCountry="no"
    specialStatus="no">
    <name xml:lang="en">Australia</name>
    <code2>AU</code2>
    <code3>AUS</code3>
  </country>
  ...
</countries>

So in your constraints you (will be able to say)
  <rule context="countryInEu">
        <let name="countryList"
            value="document('http://www.martin.com/countryList.xml')" />
        <assert
        test="$countryList/countries/country[validEuCountry = current()/@name]"/>
    </rule>

to validate that
  <countryInEu name="ES" />
is valid.

But this is very non-declarative, and therefore not much use for (say) interface-building.

> >ISO 3166 is causing headache because of the 2 letter and 3 letter forms.
> If we can cope with that (two lexical forms, one value space!) we would be
> ahead.
>
> I don't see this as a problem. They are two seperately maintained lists.
> What we need, as in the example above, is the ability to create a list that
> includes the two lists.

The general problem is when migrating from one lexical space to another,
how to enforce and establish equivalence between different lexical forms,
I think.

> >It would be great if we could have some way to validate that
> IDs are unique within a collection of documents.
>
> Is this a real world problem, or should we simply namespace IDs with the URL
> of the document containing it to create a UUID of the form
> http://www.mysite.org/mydoc.xml?id[abc] which, after all, is the XPath
> needed to identify the ID?

Yes, it is a real-world problem. Some companies maintain all their
anchors with company-wide IDs. When publishing, they resolve
the link to the particular documents which are created and deployed
at runtime. The reasons are:
 1) no difference between internal and external links
 2) documents can be renamed or moved without requiring that the references
  be rewritten or that a resource alias be used
 3) straightforward to transform into a link
 4) some idea of platform independence and managability, though
it requires a resolution layer.

Similarly, some companies build some notion of target into the ID: so
a figure is called fig001, etc. This kind of thing might be validatable
with Schematron (i.e. that fig001 resolves to a link to a <figure> in
some document.)

Cheers
Rick Jelliffe

--
DSDL members discussion list
To unsubscribe, please send a message with the
command  "unsubscribe" to dsdl-discuss-request@dsdl.org
(mailto:dsdl-discuss-request@dsdl.org?Subject=unsubscribe)