Sample code for extending the enumeration list in XML mode

Adding new values to the list is a common and necessary requirement. Pattern Designers usually want to create a method to add value in the system architecture, and this value is unknown in the design phase. How do pattern designers create a scalable and easy-to-implement list of enumerated values? This article describes several methods to achieve this goal. It is a common and necessary requirement for pattern designers and implementers to add new values to the list. Pattern Designers usually want to create a method to add value in the system architecture, and this value is unknown in the design phase. How do pattern designers create a scalable and easy-to-implement list of enumerated values? This article describes several methods to achieve this goal. It is a common and necessary requirement for pattern designers and implementers to add new values to the list. Pattern Designers usually want to create a method to add value in the system architecture, and this value is unknown in the design phase. How do pattern designers create a scalable and easy-to-implement list of enumerated values? This article describes several methods to achieve this goal.
Mode designers and implementers need a method to extend the existing enumeration list in XML mode. Unfortunately, the XML Schema specification does not allow expansion during the creation of these lists (see references. The values selected in the design phase are fixed and available. Despite such restrictions, people still use various alternatives to scale the list. Many customers who use existing models that cannot be changed often make this request. They want to maintain backward compatibility while adding new features. In this article, you will see how pattern designers can overcome obstacles to implement this function.
The enumerated list is a set of specified values for a specific data point. For example, you may view country code through a fixed value list, including DE (Germany), US (US), and JP (Japan ). Based on the given value set, what should I do when a new country is identified, such as TL (East Timor) or BA (Bosnia and Herzegovina? Customers who use the previous name list must change the implementation to accommodate new values.
When you model data in XML mode, the enumerated values are explicitly listed. Therefore, the country code list contains the enumerated values in sequence. It is often necessary to identify new values in the list and include them in the list. the pattern designer tries to find a way to extend the list. In fact, it is to build this method into the design, added value unknown during design.
Create an extensible enumeration list
When looking for a solution to this problem, it was affected by four key criteria:
First, you need to expand the list after the design phase. Whether it is to quickly establish a new trade partner or a new time-critical data field, scaling at critical times is a practical requirement.
Second, it is critical to verify the value in the parser for simplified implementation.
Third, it is essential to complete resolution and verification within a single cycle. This avoids verification in a separate cycle and parser like the Genericode solution. For some settings, adding new technologies will lead to high costs or time consumption.
Finally, the solution must be backward compatible with the original mode. Incompatible list changes cannot be called extensions.
Some people think that the enumeration list should not be extended at all. Data modelers may think that if they want to make the model contain more data and expand the model, they can create a larger model based on the product model-in fact, create a larger model as needed and reduce restrictions. If you can control the original mode and data model, this method may be ideal. However, this method does not work if you need to scale it out after the design phase.
Some people think that the key to extending the enumeration list is not to use the XML mode to verify the parser. Genericode (see references) is recommended to verify the enumeration list on layer 2, out of the initial XML schema parser verification process. This theory is correct, and the application of this method will become more and more extensive. However, this solution cannot be implemented if it is to be completed within a resolution cycle. In some cases, the second verification cycle is not possible.
Of course, you can create new elements in the new list. However, the original mode cannot be backward compatible. Our goal is to implement an extensible list while maintaining backward compatibility (see references ).
For the purpose of this article, the assumptions made here are based on my experience dealing with customers-that is, the need to extend the existing enumeration list with value-added. In addition, I assume that the XML Schema parsing and verification operations are completed in one step.
Necessary conditions for extending the enumeration list
The extension example has four necessary conditions:
The enumeration list can be expanded after the design phase.
Use a parser to verify the enumeration list.
Verify the enumeration list within a period.
Maintain backward compatibility with the original mode.
For example, a team needs to process the enumerated list (or any existing list) of a regional industrial association as an example and use the modified mode component. The previous mode provides an enumeration list of the MaritalStatus component and value, as shown in listing 1.
List 1. marital status enumeration list

Assume that a company wants to use these values, and also supports its key trading partners to use another value. CivilUnion is an extended value. The company identifies that the value is not in the original mode. However, in terms of semantics, it is also possible to use the existing element-MaritalStatus. How can companies achieve this?
Back to top
Solution 1: edit the original mode to include the new enumerated value
Of course, editing the original mode to include new enumerated values is the most direct method. Retained local copies of the pattern, and then edit these pattern to support the enumerated values used by the company.
Advantages: easy to implement
Disadvantages:
You need to edit the original mode. these modes will gradually change and cannot be controlled. If you expand an existing list, the creator (trade partner, association, etc.) may want to release a new version of the list. You need to spread the edited content to each new version.
Manual editing mode may cause unexpected editing errors.
If you cannot (or do not want) edit the original mode, you need an alternative.
Back to top
Solution 2: Create a new enumeration list and add it to the original list
The second option is to create a new enumeration list and add it to the original enumeration list. Listing 1 shows the original marital status list. Listing 2 shows the list of newly created enumerations.
List 2. list of new marital status enumeration

Use Mark it with the original list, as shown in listing 3.
Listing 3. combining the two lists

The solution still needs to edit the mode-converting the element MaritalStatus from the MaritalStatusType type to the MaritalStatusType_Union type. Not much changed, but there are still some manual edits.
Advantage: The original enumeration list is not changed.
Disadvantages:
All values in the design phase must be known to prevent future binding of the solution.
Yes Tags are supported, but sometimes they cannot be implemented by tools.
Back to top
Solution 3: Create a mode and combine it with the original enumeration type
Now let's take a look at the population data case about eye color. Listing 4 shows this list.
Listing 4. Person Eye Color enumeration list

Next, create a pattern (a regular expression) that uses the new value ). This mode is an arbitrary string prefixed with x. X: a plotting program between the standard enumeration list and the extended list. Listing 5 shows this mode.
Listing 5. extended regular expressions

Finally, use Mark the combined list and mode, as shown in listing 6.
Listing 6. combination of enumeration list and extended mode

The same node has standard and extended values. The two values are easy to separate and can be verified by the parser, as shown in listing 7.
Listing 7. XML Example

 
  Black
  
 
  x:Teal
 

Advantages:
The same element can be used for all data.
Use a parser to verify the basic enumeration list.
Clearly separate extended values.
This solution allows binding new values later.
Disadvantages:
The content of the element must be parsed to determine whether it has been extended.
The pattern parser must support regular expressions.
Yes Tag support.
Back to top
Solution 4: Use separate fields for extension
In this solution, the enumerated fields remain unchanged. However, you need to design an extension field in the pattern to accommodate the added value. In this example, the initial list is dependent (the relationship between the beneficiaries of employment and the dependents), as shown in listing 8.
Listing 8. dependency enumeration list

You need an additional property-extension-that can hold new values -. Listing 9 shows this attribute.
Listing 9. extension attributes of dependency

Listing 10 shows some XML instances that reflect extension.
Listing 10. example XML instance

 
  Child
  
 
  Extension
 

Advantages:
You do not need to edit the original mode.
This solution allows binding new values later.
Explicitly design the extension method in the original mode.
Disadvantages:
In the design phase, the extension method must be designed in each enumeration list.
You must set enumeration values in the element instead of in the attribute.
Back to top
Solution 5: document-based approach-combined with strings
Note: Solution 5 and solution 6 violate the verification requirement within a period. However, I will introduce them here because these methods can be used in many actual environments.
In the 5th solutions, use Mark to combine the enumerated list with a string. In fact, this solution prompts the receiving system which values are standard (including packaging and spelling ). But in fact, string fields can store any value. Therefore, the parser does not verify the value. Conversely, these values are verified in the second cycle or in the application that receives the data. Some XML organizations use this solution.
Listing 11 shows Returns an enumerated list and Integration. Because any value can be a string, you do not need to verify the enumeration list. Standard values are recommended.
Listing 11. DayOfWeek enumeration list combined with strings

Advantage: you can add any extension value, even when binding later.
Disadvantages:
The parser does not verify the enumerated value. it is verified in the second step.
Yes Tag support.
Back to top
Solution 6: document-based approach-use
To use this method, place the actual enumerated values Mark and keep the data field as a simple string. Listing 12 shows the enumerated values.
Listing 12. Enumeration value in the tag

Advantages:
You can add any extension value, even when binding later.
Only the simplest XML schema features are required.
Disadvantage: the parser does not verify the enumerated value.
Back to top
Methods not discussed
I have omitted several other solutions for extending the enumeration list. The following describes two unused methods:
Use Tag: Generally, this feature does not use the XML mode, and generally cannot be implemented using tools. This method is often considered to be the best practice to avoid redefinition.
Replace the Union list containing all values with the substitutionGroup element: an outstanding solution that uses replacement groups and conjoins. Combine the original list with the new list to create a complete enumerated list, and then mark (or Mark) to replace a global scope element. The disadvantage of this method is that the replacement cannot derive a valid union. the replacement requires two components from the same base type. Extension and restriction are two effective methods of replacement. However, according to the XML Schema Specification, union is not a valid derivative technology (see references ).
Back to top
Conclusion
Designers and implementers in XML mode need a way to extend the existing enumeration list. Once the original list is created, the specification cannot be extended. Therefore, you need to find a method to actually implement the extension. You can use the examples in this article to design and extend the enumeration list. Each method has advantages and disadvantages, and none of them is the best method in all cases. So what method should I use?
Consider these empirical rules:
If you are used to editing the original enumeration list or mode and know all the enumerated values to be extended during the design phase, it is best to use solution 1 (manually edit the original list) or solution 2 (create a new list and add it to the original list ).
If you want to use the same semantic element to include the basic enumeration list and extended enumeration list, consider Solution 3 (associated with the mode ).
If you allow fields in the original list to be different from the extended list, you can use Solution 4 (independent fields ).
If you do not want to parse the enumerated values in the parser, consider the Genericode method or use Solution 5 or solution 6.
These guiding principles allow pattern designers to find practical best practices and help them create easy-to-implement, scalable enumeration lists.
XML mode and XML instance example ExtendEnumeratedListsCode.zip 2KB

The above is a detailed explanation of the sample code for extending the enumeration list in XML mode. For more information, see other related articles in the first PHP community!