[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]

Re: [rest-practices] Namespace qualifying respresentation types



On Mon, 2010-05-03 at 14:51 -0700, David Lutterkort wrote:
> On Fri, 2010-04-30 at 16:06 +0100, Eoghan Glynn wrote:
> > On Fri, 2010-04-30 at 16:19 +0200, Daniel Veillard wrote:
> > > On Thu, Apr 29, 2010 at 11:55:07AM +0100, Eoghan Glynn wrote:
> > > > Folks,
> > > > 
> > > > I wanted to get the group's feeling for the use of namespaces in
> > > > representation types.
> > > > 
> > > > The context for the question initially comes from a discussion about how
> > > > action/operations were to be modelled in RHEVM-API, particularly how to
> > > > capture the action-specific parameter types in the schema. In XML schema
> > > > terms, my first cut was to use an xs:any within the action element, but to
> > > > restrict the contained type to the local namespace. Which of course requires
> > > > that a target namespace is defined in the first place.
> > > 
> > >   Why XML Schemas ? Why not Relax-NG instead.
> > 
> > 
> > Yeah, I'd love to learn RELAX NG properly.
> > 
> > However on the RHEVM-API project we've codegen'd the JAXB model from
> > schema, and unfortunately the JAXB compiler's support for RNG is marked
> > "(experimental,unsupported)" so I'd be a bit nervous about relying on
> > it.
> 
> Trang[1] will convert from rng (or rnc) to xsd. And it's written in
> java.

Yeah, we used that already - I'm going to play around with adding it to
our build process so we can use RNG

The reason being that rather than having:

  <xs:complexType name="Storage">
    <xs:sequence>
      <xs:element name="type" type="StorageType" minOccurs="1" maxOccurs="1"/>
      <xs:choice>
        <xs:group ref="NfsStorage"/>
        <xs:group ref="IscsiStorage"/>
      </xs:choice>
    </xs:sequence>
  </xs:complexType>

  <xs:simpleType name="StorageType">
    <xs:restriction base="xs:string">
      <xs:enumeration value="NFS"/>
      <xs:enumeration value="ISCSI"/>
    </xs:restriction>
  </xs:simpleType>

  <xs:group name="NfsStorage">
    <xs:sequence>
      <xs:element name="host" type="xs:string"/>
      <xs:element name="path" type="xs:string"/>
    </xs:sequence>
  </xs:group>

  <xs:group name="IscsiStorage">
    <xs:sequence>
      <xs:element name="LUN" type="xs:int"/>
      <xs:element name="IP" type="xs:string"/>
      <xs:element name="port" type="xs:short"/>
    </xs:sequence>
  </xs:group>

we could have:

  <define name='storage'>
    <element name='storage'>
      <choice>
        <ref name='storagenfs'/>
        <ref name='storageiscsi'/>
      </choice>
    </element>
  </define>

  <define name='storagenfs'>
    <attribute name='type'>
      <value>NFS</value>
    </attribute>
    <ref name='host'/>
    <ref name='path'/>
  </define>

  <define name='storageiscsi'>
    <attribute name='type'>
      <value>ISCSI</value>
    </attribute>
    <ref name='LUN'/>
    <ref name='IP'/>
    <ref name='port'/>
  </define>

which much more clearly shows the relationship between the 'type'
attribute and the content

Cheers,
Mark.


[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]