report about xml attribute

严禁转载，使用请注明出处：

http://alex2012-c.j.overblog.com/

组里的任务，自己写了一个研究报告，主要研究了现在的系统，已经给PM一个关于xml的指导。

1 Backward & Forward compatibility

Designing XML Schemas to be backward or forward compatible is a popular approach to data versioning. In this chapter, some basic information about backward and forward compatibility will be presented.

1.1 Backward compatibility

1.1.1 Context and definition

When a server (the receiver of an XML query message) enhances its functionality, the new messages version/release must be backward compatible so that the old clients software designed for the previous version/release can be used once again with minimal or no modifications, with the new version, remaining unchanged until they are modified to implement the new functionality included in the new version release.

A message grammar[1] version V001.2 is backward compatible with a version V001.1 if and only if all messages validated by the grammar V1 are validated by the new grammar V2.

1.1.2 Consequences

Backward compatibility implies that all mandatory elements in the old version are present in the new version/release. A standard defines a set of possible implementations. With a new version of the standard you have to make sure you define a bigger set that includes the previous one. It means that we can only:

• Add conditional elements or attributes;
• Increase repetitions;
• Enlarge the variable size data types;
• Be more permissive on the characters accepted.

The requests to update the standards will only be accepted if they are backward compatible.

When backward compatibility is not possible, and several clients exist using the old version, a new transaction (message pair) must be created and the old one phased out.

1.2 Forward Compatibility

1.2.1 Definition

A message grammar[2] V1 is forward compatible with a version V2 if all messages validated by V2 are also validated by V1

Note:

Client software forward compatibility implies that old client software (the sender of the XML query message) could process new message version by simply ignoring the additional data contained in the new version/release of the response.

Note2:

V1 is forward compatible with V2 is not equivalent to V2 is backward compatible with V1. Indeed V2 could have new mandatory elements, which breaks backward compatibility of V2 but does not break forward compatibility of V1.

1.3 Versioning: version="MAJOR.MINOR"

Each new release will be accompanied by release notes documenting the changes done.

Both Schemas version (request and response) will be bumped, none backward compatible message release will have the major version number incremented. But the fact now is FOM misses request and response elements so far.

If changes are backward compatible it is sufficient to increase the minor version number.

If both messages (request and response) of a service are not changed in the new release, then the version remains the same.

[1] Set of definitions describing the message use by software to decode it.

[2] Set of definitions describing the message used by software to decode it.

2 Attribute Vs. element Guidelines

2.1 Context

For some cases, we should choose whether to use attribute or element in XSD.

Examples here:

In this chapter, there are some general guidelines between elements and attributes overall. I will provide some basic ideas of how to choose between them.

2.2 Principle of core content

If the information in question is part of the essential material that is being expressed or communicated in the XML, put it in an element. For human-readable documents this generally means the core content that is being communicated to the reader. For machine-oriented records formats this generally means the data that comes directly from the problem domain.

If the information is peripheral or incidental to the main communication, or purely intended to help applications process the main communication, use attributes. This avoids cluttering up the core content with auxiliary material. For machine-oriented records formats, this generally means application-specific notations on the main data from the problem-domain.

For the example in section 6.1, if we want the “owner” message to be read by user and be communicated in the XML, it’s better to put it in element.

2.3 Principle of structured information

If the information is expressed in a structured form, especially if the structure may be extensible, use elements. On the other hand: If the information is expressed as an atomic token, use attributes.

Elements are the extensible engine for expressing structure in XML. Almost all XML processing tools are designed around this fact, and if you break down structured information properly into elements, you'll find that your processing tools complement your design, and that you thereby gain productivity and maintainability.

Attributes are designed for expressing simple properties of the information represented in an element. If you work against the basic architecture of XML by shoehorning structured information into attributes you may gain some specious terseness and convenience, but you will probably pay in maintenance costs.

Dates are a good example: A date has fixed structure and generally acts as a single token, so it makes sense as an attribute (preferably expressed in ISO-8601).

But in FOM message, “Time” is a part of OperationTimeDuration, we should communicate this information with users, so we should better keep it this way:

2.4 Principle of readability

If the information is intended to be read and understood by a person, use elements. In general this guideline places prose in element content.

If the information is most readily understood and digested by a machine, use attributes. In general this guideline means that information tokens that are not natural language go in attributes.

URLs are a great example: People have learned to read URLs through exposure in Web browsers and e-mail messages, but a URL is usually not much use without the computer to retrieve the referenced resource. For this reason I recommend putting URLs in attributes.

2.5 Principle of element/attribute binding

Use an element if you need its value to be modified by another attribute. XML establishes a very strong conceptual bond between an attribute and the element in which it appears. An attribute provides some property or modification of that particular element. Processing tools for XML tend to follow this concept and it is almost always a terrible idea to have one attribute modify another.

For example, if you are designing a format for a restaurant menu and you include the portion sizes of items on the menu, you may decide that this is not really important to the typical reader of the menu format so you apply the Principle of core content and make it an attribute. The first attempt is:

<menu>

<menu-item portion="250 mL">

<name>Small soft drink</name>

</menu-item>

<menu-item portion="500 g">

<name>Sirloin steak</name>

</menu-item>

</menu>

Following the Principle of structured information you decide not to shoehorn the portion measurement and units into a single attribute, but instead of using an element, you opt for:

<menu>

<menu-item portion-size="250" portion-unit="mL">

<name>Small soft drink</name>

</menu-item>

<menu-item portion-size="500" portion-unit="g">

<name>Sirloin steak</name>

</menu-item>

</menu>

The attribute portion-unit now modifies portion-size, which as I've mentioned is a bad idea. An attribute on the element menu-item should modify that element, and nothing else. The solution is to give in and use an element:

<menu>

<menu-item>

<portion unit="mL">250</portion>

<name>Small soft drink</name>

</menu-item>

<menu-item>

<portion unit="g">500</portion>

<name>Sirloin steak</name>

</menu-item>

</menu>

So we can see some of the problems with attributes are:

• attributes cannot contain multiple values (child elements can)
• attributes are not easily expandable (for future changes)
• attributes cannot describe structures (child elements can)
• attributes are more difficult to manipulate by program code