Subject: [mile] 5070bis schema clean up

From: "Roman D. Danyliw" <[email-masked]>
Date: Tue, 21 Jul 2015 08:18:31 +0000

Hello WG!

In Issue #54, we're tracking a need to reorganize the schema.  The specifics of this reorganization were previously scoped as:

(1) Fix inconsistent white-spacing 
(2) Consider declaring each of the classes individually. Do not nest declarations. This helps code generators that parse the schema 
(3) Consider declaring each of the enumerated attribute types outside of the attributes that use them. 

As of the -14 draft, progress has been on (2) and (3).  

Per (2), there are no more nested complex or simple definition of elements demonstrated in the "Old Style #1" and "Old Style #2" below.  All declarations will following the style demonstrated by "New Style #1" below.

--[ Old Style #1: Nested ComplexType ]--
 <xs:element name="WindowsRegistryKeysModified">
    <xs:complexType>
      <xs:sequence>
        <xs:element name="Key" maxOccurs="unbounded">
          <xs:complexType>
            <xs:sequence>
...
</xs:element>

--[Old Style #2]--
<xs:element name="ThreatActor">
  <xs:complexType>
    <xs:sequence>
      <xs:choice>
        <xs:sequence>
          <xs:element name="ThreatActorIdD
                      type="xs:string"/>
... 
</xs:element>
--[end Style #2]--

--[New Style #1]--
<xs:element name="ThreatActor">
  <xs:complexType>
    <xs:sequence>
      <xs:choice>
        <xs:sequence>
          <xs:element ref="iodef:ThreatActorID" />
... 
</xs:element>

<xs:element name="ThreatActorID" type="xs:string"/>
--[end new Style #1]--

** Does this satisfy the needs of implementers previously struggling with using auto-code generators parsing the schema?

Per (3), many enumerated attributes were declared inline per "Old Style" below.  Now all enumerated lists are declared separately as a simpleContent and then referenced as a type by the relevant attribute per "New Style" below.

--[ Old Style ]--
<xs:element name="RecordPattern">
...
  <xs:attribute name="type" use="required">
    <xs:simpleType>
      <xs:restriction base="xs:NMTOKEN">
      <xs:enumeration value="regex"/>
      <xs:enumeration value="binary"/>
      <xs:enumeration value="xpath"/>
      <xs:enumeration value="ext-value"/>
    </xs:restriction>
  </xs:simpleType>
...
</xs:element>
--[ end Old Style ]--

--[ New Style ]--
<xs:element name="RecordPattern">
...
   <xs:attribute name="type"
                          type="recordpattern-type-type"
                          use="required"/>
...
</xs:element>

<xs:simpleType name="recordpattern-type-type">
  <xs:restriction base="xs:NMTOKEN">
    <xs:enumeration value="regex"/>
    <xs:enumeration value="binary"/>
    <xs:enumeration value="xpath"/>
    <xs:enumeration value="ext-value"/>
  </xs:restriction>
</xs:simpleType>

** Does this satisfy the needs of implementers previously struggling with using auto-code generators parsing the schema?
** Current these declaration have a name with a suffix of "-type".  Is there some other convention the group would like to use, say "-dictionary" or "-vocabulary".  I suggested it exclusively for readability.
** Do we want to place all of the enum type declarations into a separate xml file that is imported.  This change might improve readability of the schema and perhaps make it easier for IANA to load all of the entries into registries?

Roman

---

From: Daisuke MIYAMOTO <[email-masked]>
Date: Wed, 22 Jul 2015 17:56:29 +0900

Dear Roman,

 In short, some code generators, namely JAXB (for Java)
and PyXB (for Python) can build libraries that seemed to work fine.

 For other code generators, this is still in working progress,
but some technological issue were raised. For example, another generator
could not import external schema via http,
whereas it supported to import via local file system.　
I'm looking for work around.

Best regards,
Daisuke

On 2015/07/21 17:18, Roman D. Danyliw wrote:
> _______________________________________________
> mile mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/mile
>

---

From: Daisuke MIYAMOTO <[email-masked]>
Date: Thu, 23 Jul 2015 22:06:54 +0900

Hello Roman,

 Yes. Some code generators needed to download xsds to local disk, and
also needed to set appropriate parameters while converting. Currently,
code generators for Python, Java, C++, and C# worked. Generated codes
are available at:

https://github.com/daisu-mi/IODEF-codegen

The XSD is extracted from your latest draft,
http://tools.ietf.org/html/draft-ietf-mile-rfc5070-bis-14

Kind regards,
Daisuke

On 2015/07/22 21:17, Roman D. Danyliw wrote:
> Good afternoon Daisuke!
> 
> Thank you so much for running the updated schema through multiple code generators and giving us feedback. This analysis is very helpful!
> 
> The one shortcoming you found of of some generators not being able to import schemas over http doesn't seem to be something we can fix in the draft.  Is the fix as simple as an implementor manually downloading the referenced schemas and changing the 5070bis schema to point to the downloaded files from a local file system?
> 
> If there is anything more that needs to do to the schema please let us know.
> 
> Thanks,
> Roman
> 
> 
> 
>> On Jul 22, 2015, at 10:57 AM, Daisuke MIYAMOTO <[email-masked]> wrote:
>>
>> Dear Roman,
>>