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: Issue: overriding attributes



> That is not the only one we don't have.
>
> - the capability to declare patterns as a restriction of another and
>   let the processor check it.

If the goal is to be able to valid W3C XML Schemas, then there is nothing 
needed here.

> - multipart key

That's true.  But keys in XML Schema are pretty much a separate world from 
the rest of validation.

> - runtime type substitution by using xsi:type. From the way I see it, this
>   is by far the biggest problem.

This is an important, but I believe we can handle this by:

- treating xsi:type as a normal attribute
- using <value type="QName">
- using combine="choice"
- using Murata-san's double indirection technique

Suppose we have an element X with complex type A, where complex type A 
contains a single empty element Y, and a complex type B derived by 
extension from A adding an empty element Z.  We could translate this into 
something like the following:

<define name="X.element">
  <element name="X">
    <ref name="A.content.ref"/>
  </element>
</define>

<define name="A.content.ref">
  <optional>
    <attribute name="xsi:type">
      <value type="QName">A</value>
    </attribute>
  </optional>
  <ref name="A.content"/>
</define>

<define name="A.content">
  <ref name="Y.element"/>
</define>

<define name="Y.element">
  <element name="Y">
    <empty/>
  </element>
</define>

<define name="B.content">
  <ref name="A.content"/>
  <ref name="Z.element"/>
</define>

<define name="A.content.ref" combine="choice">
  <attribute name="xsi:type">
    <value type="QName">B</value>
  </attribute>
  <ref name="B.content"/>
</define>

<define name="Z.element">
  <element name="Z">
    <empty/>
  </element>
</define>

> - lax validation

This is awkward, but I think it can be done.  It's just a matter of 
defining a pattern along the lines of:

<define name="lax">
  <choice>
    <ref name="X.element"/>
    <ref name="Y.element"/>
    ..
    <element>
      <anyName>
        <except>
          <name>X</name>
          <name>Y</name>
          ...
        </except>
      </anyName>
      <ref name="lax"/>
    </element>
  </choice>
</define>

(or something like that, I'm not up on the details of lax validation) where 
X, Y, ... are the elements defined in the Schema.

> ... and more.

Such as?

>
> So as for your proposal,

I am not actively proposing this. I just asking the question of whether 
it's a problem that it is awkward to implement this schema feature in RELAX 
NG.

> 1. I don't think its widely used

Have you looked at many schemas to verify this or are you just guessing? 
One widely used schema that uses this is the schema for schemas.

James





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


Powered by eList eXpress LLC