[examplotron] Attributes

From: Jonathan Lang <dataweaver42@yahoo.com>
Date: Sat May 22 2004 - 07:40:59 UTC

A two-part solution (disregard my previous suggestions; the viable
portions have been included here):

Part 1 - @eg:requires
To handle the issue of whether existing attributes are optional or
required, add an "eg:requires" attribute containing a list of attribute
names. Any attribute in that element which does not appear in this list
gets wrapped in an <optional> tag.

Part 2 - 'attribute="{...}"'
The existing mechanism for specifying the contents of the attribute. The
one drawback to this approach is that if the attribute's value is being
used to explicitly define its data type, it can't actually contain a
value. See Part 3 for a solution to this.

The three dots get replaced by a syntax derived from RELAX NG's compact

  1. remove attributes and elements: they aren't allowed within
  2. remove mixed: without elements, any mixed patterns would simplify to
     either text or notAllowed.
  3. empty and text can't go within group, interleave, zeroOrMore, or
     oneOrMore: they can only be grouped or interleaved with each other
     or with notAllowed, any such pattern would simplify to one of empty,
     text, or notAllowed, and zeroOrMore or oneOrMore of any of these
     simplifies to itself. The only "leaf" patterns that can be in these
     patterns are data and value.
  4. remove list: the presence or absence of list can easily be inferred
     from the presence or absence of group, interleave, zeroOrMore, or

The following changes aren't neccessary, but provide a level of
streamlining which could be useful:

  1. notAllowed only makes sense if the Examplotron schema is going to be
     C<included> in another RELAX NG pattern. If you're not going to
     mess with this, you can remove notAllowed.
  2. likewise, the grammar pattern can be removed and replaced by define,
     using the same trick that Examplotron uses to embed definitions in
     the russian-doll design.
  3. without grammar patterns, Examplotron probably has no use for
     parentRef patterns: the only use would be to refer to a definition
     in a RELAX NG pattern that references the Examplotron schema.

Part 3 - <eg:attribute>
This is very similar to the solution given in v0.7, but with a fundamental
difference in perspective: the eg:attribute element should not declare
attributes, per se; instead, it should provide a mechanism for associating
@eg:content, @eg:define, and @eg:occurs with existing attributes. That

  <?xml version="1.0" encoding="UTF-8"?>
  <foo xmlns:eg="http://examplotron.org/0/">
    <eg:attribute name="bar">1</eg:attribute>

should not be legal; instead, use:

  <?xml version="1.0" encoding="UTF-8"?>
  <foo bar="1" xmlns:eg="http://examplotron.org/0/">
    <eg:attribute name="bar" occurs="."/>

Of course, in this case Part 1 provides a better solution:

  <?xml version="1.0" encoding="UTF-8"?>
  <foo bar="1" eg:requires="bar" xmlns:eg="http://examplotron.org/0/"/>

The eg:attribute element is part of the non-iconic 20%; it's there
primarily to allow for an alternative to the 'attribute="{content}"'
syntax which leaves the original atribute's value free for use, to provide
a means to add labels to attribute definitions, to handle "wildcard
attributes", and to explicitly declare optional attributes which the
definition wouldn't otherwise include. For instance:

  <order no="5" date="2003-02-01">
    <eg:attribute name="no" content="xsd:unsignedInt"/>
    <eg:attribute name="date" content="xsd:date"/>
  <element name="order">
      <attribute name="no">
        <data type="xsd:unsignedInt"/>
      <attribute name="date">
        <data type="xsd:date"/>

  <a href="http://examplotron.org/">
    <eg:attribute name="href" define="href"/>
  <element name="a">
    <ref name="href">
  <define name="href">
      <attribute name="href">

    <eg:attribute name="* - eg:*"/>
  <element name="node">
              <nsName name="eg"/>

  <img src="http://host.com/image.gif">
    <eg:attribute name="alt"/>
  <element name="img">
      <attribute name="src">
      <attribute name="alt">

* The value of eg:attribute/@name uses a subset of RELAX NG's compact
syntax - namely, nameClass and whatever goes with it. If the nameClass
includes anyName or nsName, the resulting rng:attribute pattern gets
wrapped in a rng:oneOrMore tag; note that it may further end up being
wrapped in a rng:optional tag, depending on the value of the @occurs

* The value of eg:attribute/@define is a RELAX NG identifier.

* The value of eg:attribute/@occurs can be one of "?" or ".", maybe "-".
The default value is "?". Note that, with the possible exception of "-",
this attribute is completely redundant with Part 1's @eg:requires

* The value of eg:attribute/@content follows the same syntax as the
section between the curly braces in Part 2. This is completely redundant
with Part 2 unless you need to use the attribute's value for an actual
value. The default value for eg:attribute/@content is "text".

* you might even allow eg:attribute/@default value for an attribute:

    <eg:attribute name="bar" default="0"/>
  <element name="foo">
      <attribute name="bar" a:defaultValue="0">

IMHO, the majority of the non-iconic 20% could be handled by the above
eg:attribute element, an eg:element element with a name attribute which
behaves the same way as eg:attribute/@name above, and an eg:choice element
which translates directly to rng:choice. The remaining RELAX NG
capabilities which Examplotron lacks fall mainly in the scope of inclusion
or referencing of other Examplotron schema - and I'm not sure that it's a
capability that belongs in Examplotron. I'll post a separate message for
my thoughts on how to handle the non-iconic 20% once I've put a bit more
thought into it.

Jonathan "Dataweaver" Lang

Do you Yahoo!?
Yahoo! Domains Claim yours for only $14.70/year
Received on Sat May 22 09:41:10 2004

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