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



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

> The second option would lead to more complex stuff such as:
>
>  <foo bar="occurs=?, type=xsd:integer"/>

Yuck!

I think attributes are the real challenge for an example-based syntax. 
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.

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

James



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


Powered by eList eXpress LLC