[examplotron] Re: What needs to be done?

Jonathan,
        I took the previous XSLT version of examplotron and provided for
a set of extensions.

        One major one was for full namespace support using the same
prefixes in asserts as used in the examples provided

        The next was to add support for attributes as follows:

        If there was an element level attribute (eg:occurs) I introduced
an attribute level attribute (eg:occursAttr). The contents of this
attribute is a list, formatted as follows:
         (attributeName[values])

So you get: <element attr1="example" attr2="example">Example</element>
could be marked up as:

        <element attr1="example" attr2="example"
                eg:occurs="?" eg:occursAttr="attr1[?]
attr2[.]">Example</element>

        From this you can see that using attribute I was able mark up
both elements and attributes. I have found this 'less intrusive' on the
undelying example than the introducing eg:elements.

        This works for all examplotron attributes.

        An alternative to this that also works is to suffix the action
attribute name with the attribute name of the attribute affected. So
you get eg:occurs-attr1="?". This work well also.

        I favour this attribute only approach as it means that the Xpath
of any element or attribute in the example is not changed in any way,
including position. I also feel that as soon as you intriduce elements
you are moving too close to a schema language and you may as well use
relax first off.

        I am also working on something from OASIS called Content Assemby
Mechanism that tries to take the examplotron approach to structure along
with a set of rules and also linking to base datadictionaries or
libraries. This means that we can use the one document to provide both
validation of xml files including cross field validation but also
produce documentation about the options by extracting definitions from
an underlying datadictionary. Without the idea of using examples we
would not have gone down that route and we owe a great deal to
examplotron.

Martin Roberts
xml designer,
BT Exact
e-mail: martin.me.roberts@bt.com
tel: +44(0) 1473 609785 clickdial
fax: +44(0) 1473 609834
Intranet Site :http://twiki.btlabs.bt.co.uk/twiki

-----Original Message-----
From: Jonathan Lang [mailto:dataweaver42@yahoo.com]
Sent: 10 July 2003 06:22
To: examplotron@xmlschemata.org
Subject: [examplotron] What needs to be done?

Looking over the Relax NG patterns, I note that Examplotron has analogs
to most of them. The exceptions are:

<element> {nameClass} {pattern+} </element>
<attribute name="QName"> {pattern} </attribute>
  (this _has_ been defined for <attribute name="QName"/>) <attribute>
{nameClass} {pattern?} </attribute> <choice> {pattern+} </choice> <list>
{pattern+} </list> <parentRef name="{NCName}"/> <value type?="{NCName}">
{string} </value> <data type="{NCName}"> {param* exceptPattern?} </data>
  (this _has_ been defined for <data type="{NCName}"/>) <notAllowed/>
<externalRef href="{anyURI}"/> <grammar> {grammarContent*} </grammar>

The following have Examplotron analogs, but said analogs aren't as
powerful as their RNG counterparts:

<group> {pattern+} </group>
<interleave> {pattern+} </interleave>
<mixed> {pattern+} </mixed>
  (these operate on an all-or-nothing basis with respect to the
element's
   content)

IMHO, the limitations on <group>, <interleave>, and <mixed> are
acceptable; <choice>, <list>, <notAllowed>, and <grammar> are part of
the "non-iconic 20%", and can be reasonably handled simply by creating
"eg:"-prefixed duplicates for Examplotron. The current discussion
involving attributes looks like it might resolve the issues of
<attribute name="QName"> {pattern} </attribute>, and partially resolve
the issues with <value> and <data> - that is, it would fully resolve
those issues when dealing with the contents of attributes. That leaves:

partially accounted for:
  <value type?="{NCName}"> {string} </value>
  <data type="{NCName}"> {param* exceptPattern?} </data>
not accounted for:
  <element> {nameClass} {pattern+} </element>
  <attribute> {nameClass} {pattern?} </attribute>
  <parentRef name="{NCName}"/>
  <externalRef href="{anyURI}"/>

Datatypes in elements
=====================
  <value type?="{NCName}"> {string} </value>
  <data type="{NCName}"> {param* exceptPattern?} </data>

You could handle this by interleaving valueMarkup (from the other
discussion) with elements in the current element's contents - for
instance,

<root>
  true {'true' | 'false' | 'maybe'}
  <sub/>
  {(xsd:integer(maxInclusive=5) - xsd:integer 3)*}
  2
  4
</root>

NameClasses
===========
  <element> {nameClass} {pattern+} </element>
  <attribute> {nameClass} {pattern?} </attribute>

Introduce <eg:element> and @eg:attribute. For <eg:element>, the
nameClass resides (in RNG compact notation) in an optional name
attribute; for @eg:attribute, the nameClass (again in RNG compact form)
is incorporated into its value - for example, @eg:attribute="{nameClass
valueMarkup}".

Far References
==============
  <parentRef name="{NCName}"/>
  <externalRef href="{anyURI}"/>

@content can be one of
  "eg:parent {identifier}"
  "eg:externalRef {uri inherit?}"

Less bulky, and only if URIs can always be distinguished from
identifiers:
  "::{identifier}"
  "{uri inherit?}"

=====
Jonathan "Dataweaver" Lang

__________________________________
Do you Yahoo!?
SBC Yahoo! DSL - Now only $29.95 per month! http://sbc.yahoo.com
Received on Thu Jul 10 14:45:15 2003