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

On Thu, 2003-01-30 at 12:06, James Clark wrote:
> > To say that attribute
> > "bar" is optional, we could write:
> >  <bar eg:node="attribute" eg:occurs="?"/>
> That's clean, but it doesn't really buy you anything over using the 
> eg:attribute that you've imported from RNG.
>   <eg:attribute name="bar" eg:occurs="?"/>
> assuming you've extended occurs to apply to RNG elements as well.

Yes, this is very similar. The first form is just slightly nearer to the
definition of elements in Examplotron and would avoid to change the
definition of the imported elements.
> > The second option would lead to more complex stuff such as:
> >
> >  <foo bar="occurs=?, type=xsd:integer"/>
> Yuck!

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}"/>

> I think attributes are the real challenge for an example-based syntax. 

Yes and for any annotation system in general... Attributes are kind of
"final" nodes for XML, you can't derive anything from them!

> While I was designing TREX, I played with such syntaxes (based on my XSLT 
> experience with literal result elements), but I failed to find an approach 
> to handling attributes that I liked.
> I think a bit more brainstorming is required. One possibility:
>   <foo optional:bar="xsd:integer" required:baz="xsd:integer"/>
> where optional, required are bound to special Examplotron-defined namespace 
> URIs.  Would only work for local attributes, but I suspect local attributes 
> are the 80% case.
> Another is to use a syntax that is not legal XML:
>   <foo bar="xsd:integer"? />
> You could have a simple little pretransform to turn that into something 
> that was legal XML before doing the XSLT transform into RNG.

If we keep it simple, I think that something such as:

<foo bar="{?, xsd:integer}"/>

could work. We don't even have to impose an order between the number of
occurrences and the type, their lexical spaces is different enough to
avoid any confusion.

> >  <foo eg:ref="foo-content"/>
> Having an attribute on a literal element that refers to a definition for 
> the content is a nice idea, but I'm not sure whether the similarity with 
> the <eg:ref/> element that you will have imported from the RNG namespace is 
> a help or a hindrance.

That's also something I am thinking of.

For instance, it might be usefull to allow external references or
imports of Relax NG grammars in Examplotron. We could add a "type"
attribute to eg:include and eg:externalRef to specify if what's
referenced is Examplotron or Relax NG.

By default this would be Examplotron:

 <eg:externalRef href="schema.eg"/>

But Relax NG could be used to:

 <eg:externalRef href="schema.rng" type="RELAX NG"/>



> James
Read me on Advogato.
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