XML Element Structure

Returning to one of our unresolved issues from the Boston meeting, with a specific example:

Reposted from the semantics thread:

Code:

I think this example highlights some of the inconsistent structure we've introduced. Notice how the elements that actually describe the constraints require a parent <constraint> element according to the development draft, but the behavior elements have no equivalent.

I feel this additional depth leads to a lot of unnecessary verbosity. As written, the constrain open and close tags take six lines, where their contents take only five. Additionally, the implied nature of the <constraint> element can never have more than one child, making this verbosity a permanent structure.

At the same time, we've stated the constraint element is the location of the id attribute. However, the behaviors so that need not be the case.

If we remove the <constraint> parent tag, we implicitly require some a priori knowledge of the <bml> child elements to determine whether they are behaviors with sync-point attributes or not. This conflicts with encouraging the use of experimental behaviors through namespaced attributes.

One alternative is to use a parent <constraints> element that describe the type (currently behavior or constraint) of multiple child elements. I could rewrite the above example as:

Code:

In doing this, the constraint id attribute moves from the <constraint> element to the constraint description element. In the above example, we save four lines.

However, we've maintained an inconsistency between behavior elements and constraint elements, in that there is no complimentary <behaviors> group. Instead, we assume every tag in <bml> is a behavior, with a few exceptions (e.g., <constraints>, <required>). Personally, I don't like this structural inconsistency. I'd rather introduce a required <behaviors> at the fixed cost of two short lines. It also makes BML more future proof with respect to new element types (e.g., shared references to world objects/places) by providing clear boundaries.

Example using <behaviors>:

Code:

With respect to <required> tags, I don't see this explicitly conflicting with their structure, as a <required> group can contain both <behaviors> and <constraints>. However, it remains structurally inconsistent in my opinion. By delegating the required property to an attribute of the individual behavior and constraint description elements, top level group elements now serve the single purpose of identifying the general type of data represented by an element.

Thoughts? Counterpoints?