OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

relax-ng message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]


Subject: Re: [relax-ng] trang instance input module


Yes, this sounds like a very good compromise!

Thanks

Eric

On Thu, 2003-01-30 at 13:36, James Clark wrote:
> > The comma separated list of name=value is extensible but verbose. If we
> > limit the information carried in attribute values to be only the number
> > of occurrences and the type, we can simplify it to:
> >
> > <foo bar="?, xsd:integer"/>
> >
> > or, if we want to draw the attention to the fact that this value has a
> > special meaning, we can add some kind of brackets such as:
> >
> > <foo bar="{?, xsd:integer}"/>
> 
> The things about this I don't like are:
> 
> - the ? inside the attribute value: the ? conceptually applies to the 
> entire attribute not merely the value
> 
> - very non-uniform with elements (although some non-uniformity seems 
> unavoidable)
> 
> - attribute value with complex structure; generally I prefer attributes 
> that don't require too much microparsing
> 
> Perhaps the best would be to say that literal attributes are always 
> optional.  For required attributes, you have to use an element (i.e. 
> eg:attribute), but the default for such an element would be that the 
> attribute is required (as in RELAX NG). My thinking is that
> 
> - most of the time attributes are optional
> 
> - element syntax for attributes is least painful when the attribute is 
> required
> 
> In this case, the value of a literal attribute would just specify the 
> allowed value, not whether it was required/optional.  Here, one could 
> follow the compact syntax and say that a name with a prefix refers to a 
> builtin datatype and a name without a prefix refers to a definition.
> 
> For example,
> 
>   <foo bar="xsd:int"/>
> 
> turns into
> 
>   element foo { attribute bar { xsd:int }? }
> 
> and
> 
>   <foo bar="number"/>
> 
> turns into
> 
>   element foo { attribute bar { number }? }
> 
> For elements, we could have an eg:type attribute that allows a name with 
> the same interpretation as the value of a literal attribute.  For example,
> 
>   <foo eg:type="xsd:int"/>
> 
> turns into
> 
>   element foo { xsd:int }
> 
> and
> 
>   <foo eg:type="number"/>
> 
> turns into
> 
>   element foo { number }
> 
> James
-- 
Lisez-moi sur XMLfr.
                       http://xmlfr.org/index/person/eric+van+der+vlist/
------------------------------------------------------------------------
Eric van der Vlist       http://xmlfr.org            http://dyomedea.com
(W3C) XML Schema ISBN:0-596-00252-1 http://oreilly.com/catalog/xmlschema
------------------------------------------------------------------------



[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]


Powered by eList eXpress LLC