[examplotron] Re: Choices and other markup

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}"
in

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

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

   [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
example:

     <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?

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

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

  <actor>
    <name eg:choice="1">
      John Q. Smith
    </name>
    <firstname eg:choice="2">
      John
    </firstname>
    <middlename eg:choice="2">
      Q.
    </middlename>
    <lastname eg:choice="2">
      Smith
    </lastname>
    <role eg:occurs="*">
    <birth eg:choice="1">
      1972-05-30
    </birth>
    <birthyear eg:choice="2">
      1972
    </birthyear>
    <birthmonth eg:choice="2">
      May
    </birthmonth>
    <birthday eg:choice="2">
      30
    </birthday>
  </actor>

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!
http://sbc.yahoo.com
Received on Wed Jun 25 04:56:25 2003