[examplotron] Re: Advanced handling of attributes

Hi,
        Why can schematron asserts be applied to attributes. ON the old
Examplotron rules could be attribute based.

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: Eric van der Vlist [mailto:vdv@dyomedea.com]
Sent: 06 July 2003 07:11
To: examplotron@xmlschemata.org
Subject: [examplotron] Re: Advanced handling of attributes

Hi Jonathan,

On Sun, 2003-07-06 at 07:47, Jonathan Lang wrote:
> To the best of my knowledge, the following is an accurate summary of
> what has been done with attribute annotations to date:
>
> <my:element assert="boolean XPath expression"
> content="one of eg:group, eg:mixed, eg:interleave,
> an xsd:simpleType, or
> an xsd:NCName that matches one of //@define"
> define="an xsd:NCName which is unique within //@define"
> occurs="one of -, ?, ., *, or +"/>
>
> When applying the attribute annotations to the eg:attribute element
> annotation, you need to restrict some of the capabilities. Assertions

> are fine as is; they give you a way of validating the attribute's
> value.

Assertions would still be an issue since they are currently translated
as Schematron rules and Schematron rules can't be applied to
attributes...

> Occurrence is also fine as
> is: "-" means that the element can't have an attribute of this name at

> all, which is exactly as useful for attributes as it is for elements;
> "?" represents an optional attribute with a single value; "."
> represents a required attribute with a single value; "*" represents an

> optional attribute which contains a list of values; and "+" represents

> a required attribute which contains a list of values.
>
> At first glance, Content would seem to be required to be restricted to

> an xsd:simpleType; eg:group, eg:mixed, and eg:interleave are _not_
> valid options for an attribute (even implicitly; no elements within an

> eg:attribute element). But the "named content model" option _could_
> be made to work with attributes, if you allow @eg:define within an
> eg:attribute element. Doing so would require some clarification as to

> the uniqueness of a given name in @eg:define - the idea of applying an

> attribute's content model to an element, or vice versa, seems awkward
> at best; and you might be better off isolating the @eg:defines that
> are associated with attributes from the @eg:defines that are
associated with elements.

Yes.

> Once all of the restrictions are put into place, we have something
> like this for eg:attributes:
>
> <attribute name="{NCName}"
> assert="boolean XPath expression"
> content="an xsd:simpleType or
> an xsd:NCName that matches one of
//attribute/@define"
> define="an xsd:NCName which is unique within
//attribute/@define"
> occurs="one of -, ?, ., *, or +"/>
>
> IIRC, all of the above possibilities can be mapped to RELAX NG.
>
> However, I find this approach, while powerful, to be an eyesore.

I agree.

> As an
> alternative, let me propose an expanded syntax for value annotations.

> By "value annotation", I'm referring to the use of curly braces within

> the sample value of an attribute to annotate valid value types for it.
>
> The existing annotation is quite simple: an xsd:simpleType enclosed in

> curly braces. However, that only covers a small subset of what the
> eg:attribute element is capable of handling. In order to replace it,
> the value annotation needs to be able to provide suitable equivelents
> to all four of the Examplotron attribute annotations: assertions,
> content, naming, and occurrences. I propose the following:
>
> ValueAnnotation ::= '{' S? Naming? ContentType?
> (Occurrence | Assertion | Occurrence S Assertion)?
S? '}'
> Naming ::= NCName ':' S
> ContentType ::= NCName | simpleType
> Occurrence ::= '-' | '?' | '.' | '*' | '+'
> Assertion ::= 'where' XPathExpr
>
> simpleType ::= QName
>
> So:
>
> <my:element ref="{ChildCount: xsd:integer. where
> count(../*::node())=.} 1"/>
>
> would map to
>
> <my:element>
> <eg:attribute name="ref" eg:define="ChildCount"
eg:content="xsd:integer"
> eg:occurs="." eg:assert="count(../*::node())=."> 1</eg:attribute>
> </my:element>
>
> As is, the above is suitable to model attributes which would be
> #IMPLIED or #REQUIRED in a DTD; there is currently no mechanism for
> default values or #FIXED values. Under the <eg:attribute> model, the
> only solution that I can see would be to introduce an optional 'value'

> attribute unique to eg:attribute: when it's absent, eg:occurs="?" and
> "*" still map to #IMPLIED while "." and "+" map to #REQUIRED; when
> it's present, "?" and "*" map to the default value while "." and "+"
> map to #FIXED. In the value annotation shorthand, the equivelent of a

> value attribute could be included by inserting it between the
> Occurrence and the Assertion, and prepending it with an equal sign:
>
> ValueAnnotation ::= '{' S? Naming? ContentType?
> (Occurrence S? Default?
> | S? Default? S Assertion
> | Occurrence S? Default? S Assertion)? S? '}'
> Naming ::= NCName ':' S
> ContentType ::= NCName | simpleType
> Occurrence ::= '-' | '?' | '.' | '*' | '+'
> Default ::= '=' Value
> Assertion ::= 'where' XPathExpr
>
> <my:element
> ref="{ChildCount: xsd:integer=0 where count(../*::node())=.} 1"/>
>
> would map to
>
> <my:element>
> <eg:attribute name="ref" value="0" eg:define="ChildCount"
> eg:content="xsd:integer" eg:assert="count(../*::node())=.">
> 1</eg:attribute> </my:element>
>
> and would represent an element with an attribute that tells it how
> many child elements it must have, defaulting to none.
>
> Even if you find the fully-featured version to be too cumbersome, a
> simpler version can substantially reduce the need for <eg:attribute>,
> even if it doesn't eliminate it: if you keep the Occurrence part,
> you've eliminated the need to use <eg:attribute> to handle required
> attributes (which is noted in the specification as the most common use
of said element annotation).

Yes, I need to think more about this but can't do it right now (I am
leaving for the OSCON in Portland in a couple of hours).

Another option I have been playing with would be to allow a subset of
Relax NG compact syntax in attributes and I'd like to be as close as
possible to the compact syntax if we allow structured annotations in
attributes.

OTH, I'd also like to keep the possibility to implement Examplotron as a
XSLT transformation and there is a compromise to find between the
expressiveness of these annotations and the ease to translate them (and
understand them).

Thanks for your message. I hope I'll be able to spend some more time on
Examplotron during the summer!

Eric

> =====
> Jonathan "Dataweaver" Lang
>
> __________________________________
> Do you Yahoo!?
> SBC Yahoo! DSL - Now only $29.95 per month! http://sbc.yahoo.com

-- 
If you have a XML document, you have its schema.
                                                  http://examplotron.org
------------------------------------------------------------------------
Upcoming Schema languages tutorial (registration open):
 - July 7th   (Portland, OR)      http://makeashorterlink.com/?K27A527A4
 - August 4th (Montreal, Canada)  http://makeashorterlink.com/?U28A217A4
------------------------------------------------------------------------
Eric van der Vlist       http://xmlfr.org            http://dyomedea.com
(W3C) XML Schema ISBN:0-596-00252-1 http://oreilly.com/catalog/xmlschema
------------------------------------------------------------------------