[examplotron] Re: Advanced handling of attributes

Hi Jonathan,

Jonathan Lang said:
>
> Eric van der Vlist wrote:
>> Jonathan Lang wrote:
>> > 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...
>
> I'll drop this line of research for now, and will assume that assetions
> cannot be used on attributes (at least, not directly). If this
> changes, a temporary hack solution would be to reference the attributes
> in question using @eg:assert.

You mean defining the rules in the elements containing the attributes?
Yes, that's we usually have to do with Schematron!
>> > 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.
>
> It also might not be possible. RELAX NG doesn't appear to provide any
> mechanism for defines that can only be referenced from within
> attributes.

No, for Relax NG a pattern is a pattern and named patterns can be refered
from anywhere.>
>> 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.
>
> Note that the use of occurrence symbols that I outlined above
> contradicts the Relax NG compact syntax. In Relax NG, "pattern '+'" is
> equivelent to <oneOrMore>pattern</oneOrMore>; in the notation that I
> proposed above, "pattern '+'" would equate to <list>pattern</list>.
> Meanwhile, "pattern '*'" from Relax NG would be
> <zeroOrMore>pattern</zeroOrMore>, and from my notation it would be
> <optional><list>pattern</list></optional>.

Ooops, yes I had missed this in your post.

> Note also that Relax NG assumes that attributes are required, and uses
> the "pattern '?'" notation to make them optional; Examplotron, OTOH,
> assumes that attributes are required; therefore, a variation from the
> Relax NG compact syntax is neccessary to provide some sort of notation
> identifying required attributes.

Right.

The reason why attributes are optional by default in Examplotron is that
we've though that this was the general case. Should we reconsider this?
> I haven't found anything in the Relax NG specification which forbids an
> attribute from containing elements; nor can I find anything excluding
> groups, interleaves, zeroOrMores, oneOrMores, mixeds, parentRefs,
> emptys, externalRefs, or grammars from use inside attributes.
> Nonetheless, I can't think of any cases where any of these would be
> useful in defining the contents of a singly-named attribute (ass
> opposed to an attribute which uses a nameClass). Furthermore, ref is
> explicitly excluded from being used within an attribute, which puzzles
> me (especially since parentRef and externalRef don't appear to be so
> restricted).

I guess that you are refering to chapter 7 of the Relax NG spec:

http://relaxng.org/spec-20011203.html#restriction

If so, you must note that these restrictions apply to Relax NG schemas
after simplification and that the simplification process makes sure that
each element is defined in its own named pattern, that any element pattern
is replaced by a ref and that there is no other refs than those refering
to the definition of a single element. I have tried to explain all this in
my RNG book:
http://books.xmlschemata.org/relaxng/RngBookRestrictions.html

The consequence is that in a simplified RNG schema, avoiding that an
element is found in the definition of an attribute is translated by the
fact that no references can be found (parentRef and externalRef are
removed in the simplificatiopn process).
The principle followed by RNG is that they haven't wanted to enumerate all
the rules on the full schema but only the consequences on the simplified
schema. That makes it more difficult to understand in the spec but ends up
with fewer restrictions on the full schema (you can do pretty much what
you want if it makes sense for the instance documents).
I'll come back to the rest of your message later on!

Thanks

Eric

-- 
Freelance consulting and training.
                                            http://dyomedea.com/english/
------------------------------------------------------------------------
Eric van der Vlist       http://xmlfr.org            http://dyomedea.com
(W3C) XML Schema ISBN:0-596-00252-1 http://oreilly.com/catalog/xmlschema
------------------------------------------------------------------------