Changes between Version 1 and Version 2 of MapGuideRfc10


Ignore:
Timestamp:
Feb 27, 2007, 6:18:23 PM (17 years ago)
Author:
waltweltonlair
Comment:

Just formatting fixes...

Legend:

Unmodified
Added
Removed
Modified

  • MapGuideRfc10

    v1 v2  
    4343Telling the parser to ignore any potential new data is done by including the following element at the end of the complex element’s sequence:
    4444
    45   <xs:element name=”ExtendedData1” minOccurs=”0”>
    46     <xs:complexType>
    47         <xs:sequence>
     45{{{
     46<xs:element name=”ExtendedData1” minOccurs=”0”>
     47  <xs:complexType>
     48    <xs:sequence>
     49      <xs:any maxOccurs=”unbounded” processContent=”lax” />
     50    </xs:sequence>
     51  </xs:complexType>
     52</xs:element>
     53}}}
     54
     55Note: To further understand how this mechanism would work in the future – here is an example of adding one new element.  This additional data will be validated by new parsers, and it will be ignored by older parsers.  Note also, that this addition further provides another “space” for newer, future data.  And if the !NewStuff did not have minOccurs=”0” then all we’d need to add is the <xs:any> tag without another wrapper element.
     56
     57{{{
     58<xs:element name=”ExtendedData1” minOccurs=”0”>
     59  <xs:complexType>
     60    <xs:sequence>
     61      <xs:element name=”NewStuff” type=”xs:string” minOccurs=”0” />
     62      <xs:element name=”ExtendedData2” minOccurs=”0”>
     63        <xs:complexType>
     64          <xs:sequence>
    4865            <xs:any maxOccurs=”unbounded” processContent=”lax” />
    49         </xs:sequence>
    50     </xs:complexType>
    51   </xs:element>
    52 
    53 Note: To further understand how this mechanism would work in the future – here is an example of adding one new element.  This additional data will be validated by new parsers, and it will be ignored by older parsers.  Note also, that this addition further provides another “space” for newer, future data.  And if the NewStuff did not have minOccurs=”0” then all we’d need to add is the <xs:any> tag without another wrapper element.
    54 
    55   <xs:element name=”ExtendedData1” minOccurs=”0”>
    56     <xs:complexType>
    57         <xs:sequence>
    58             <xs:element name=”NewStuff” type=”xs:string” minOccurs=”0” />
    59             <xs:element name=”ExtendedData2” minOccurs=”0”>
    60                 <xs:complexType>
    61                     <xs:sequence>
    62                         <xs:any maxOccurs=”unbounded” processContent=”lax” />
    63                     </xs:sequence>
    64                 </xs:complexType>
    65             </xs:element>
    66         </xs:sequence>
    67     </xs:complexType>
    68   </xs:element>
     66          </xs:sequence>
     67        </xs:complexType>
     68      </xs:element>
     69    </xs:sequence>
     70  </xs:complexType>
     71</xs:element>
     72}}}
    6973
    7074In the Layer Definition and Feature Source schemas, there are approximately 35 places where we can add the extended data elements.
    … …  
    7781There are 45 types of Model objects which are instantiated during the parsing of Feature Source and Layer Definition XML data, and as indicated above, we need to add support to approximately 35 of them.  Each of these objects has a corresponding IO handler which is used by the parser to do the parsing and serialization.  The following code changes will be required to support each extended data element for each model object.
    7882
    79 To support the collection of unrecognized XML data, one IOUnrecognized handler class will be needed by each parser, the SAX2Parser for Layer Definitions and the FSDParser for Feature Source Definitions.   When unrecognized elements are found in an IO class’ StartElement() method, it will instantiate the IOUnrecognized handler which will gather the XML data, keeping it in its original format.  Upon completion of the containing IO class’ parsing, in EndElement(), that data will be transferred as a string to the model object.
     83To support the collection of unrecognized XML data, one IOUnrecognized handler class will be needed by each parser, the SAX2Parser for Layer Definitions and the FSDParser for Feature Source Definitions.   When unrecognized elements are found in an IO class’ !StartElement() method, it will instantiate the IOUnrecognized handler which will gather the XML data, keeping it in its original format.  Upon completion of the containing IO class’ parsing, in !EndElement(), that data will be transferred as a string to the model object.
    8084
    8185The round-trip is completed during serialization.  As the parser is serializing, when it reaches the end of the elements for the object, it will retrieve the unrecognized data string from the model object and write it back to the XML.  The reason why it is necessary that all new data (and <xs:any> elements) be placed at the end of sequences is so we know exactly where to write the unrecognized data back out.
    8286
    83 So, for each <xs:any> tag, we need to add to the IO handler: detection of unrecognized elements in StartElement() and creation of the IOUnrecognized handler, passing of unrecognized data to the model object in EndElement(), and writing out the unrecognized data during serialization.  Each corresponding model object will need to have one additional string property to store the unrecognized XML.
     87So, for each <xs:any> tag, we need to add to the IO handler: detection of unrecognized elements in !StartElement() and creation of the IOUnrecognized handler, passing of unrecognized data to the model object in !EndElement(), and writing out the unrecognized data during serialization.  Each corresponding model object will need to have one additional string property to store the unrecognized XML.
    8488
    8589Note that the extended data section is only intended to be an interim area for new data. The new data will eventually be put back into a non-extended data part of the schema at some point in the future.