[examplotron] Re: Choices and other markup

From: Jonathan Lang <dataweaver42@yahoo.com>
Date: Wed Jun 25 2003 - 02:56:25 UTC

Martin Roberts wrote:
> Hi,
> I have been using the XSLT version of examplotron for some time as I have
> been using subclassed schemas and examplotron has proved very useful at
> making sure that subclasses exist before using a schema check.
> There are two things that I have done differently from the 0.4 version of
> the tool.
> 1) I have marked up attributes using the following notation:
> <party eg:occursAttr=" PartyID[?] AgencyID[?]"
> PartyID="1112" AgencyID="Supplier"/>
> This square bracket notation means that I have not entered any elements
> into the Xpath which makes it easier to make sure eg:assert work more
> directly.

If you're going to require a special annotation for an attribute's default
behavior and you're unwilling to use the eg:attribute element annotation, it
might be worth considering a modification to the value annotation used by
Examplotron. By "value annotation", I'm referring to the "{xsd:unsignedInt}"

     <order no="{xsd:unsignedInt}" date="2003-02-01">

The only possible default behaviors for an attribute are (as defined in the XML

   [1] #REQUIRED
   [2] #IMPLIED
   [3] #FIXED value
   [4] value

At present, Examplotron provides user-friendly support for [2] by means of the
value annotation, and offers the eg:attribute element as a workaround for [1].
The value annotation could be extended trivially to include [4] by allowing the
{}-enclosed term to coexist with a value:

     <order no="{xsd:unsignedInt} 25" date="2003-02-01">

All that remains is a way to annotate [3]. It is conceivable to extend the
value annotation one step further to allow for user-friendly support for both
[1] and [3], thus removing the need for the eg:attribute element entirely; for

     <order no="{always xsd:unsignedInt}" date="2003-02-01">

for a required attribute, and

     <order no="{always xsd:unsignedInt}5" date="2003-02-01">

for an attribute with a fixed value of 5. The exact terminology used above may
well prove to be unsatisfactory; but the concept of including information
pertaining to default behavior in the same place that you put information
pertaining to the attribute's datatype seems feasible.

> 2) I have introduce namespacing that uses the same prefixes that are in
> the example document. This is useful as any assert is using expected
> namespaces.

I would like to see this added to the official version.

> I just realized I had not said how I would do choices in my last email.
> I feel that I would like to use an eg:choiceID attribute where the ID
> is set to the same value for any items that are I the choice and are at
> the same level in the tree.
> What do you think.

Is this the sort of thing you're thinking of?

    <name eg:choice="1">
      John Q. Smith
    <firstname eg:choice="2">
    <middlename eg:choice="2">
    <lastname eg:choice="2">

If so, I'd require every element involved in a particular choice to be adjacent
siblings - that is:

    <name eg:choice="1">
      John Q. Smith
    <firstname eg:choice="2">
    <middlename eg:choice="2">
    <lastname eg:choice="2">
    <role eg:occurs="*">
    <birth eg:choice="1">
    <birthyear eg:choice="2">
    <birthmonth eg:choice="2">
    <birthday eg:choice="2">

An element that eg:occurs="-" could be used to seperate otherwise-adjacent sets
of choices, but that's a rather ugly kludge.

We may be better off leaving choices in the realm of the 20%, and using
RELAX-NG's choice element for the purpose.

Jonathan "Dataweaver" Lang

Do you Yahoo!?
SBC Yahoo! DSL - Now only $29.95 per month!
Received on Wed Jun 25 04:56:25 2003

This archive was generated by hypermail 2.1.8 : Fri Dec 03 2004 - 14:29:48 UTC