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