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

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

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

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

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

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

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

> - 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">
    <ref name="X.element"/>
    <ref name="Y.element"/>
      <ref name="lax"/>

(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 

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


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

Powered by eList eXpress LLC