Ridiculous Time Wasting

During the meeting of the afternoon of January 25 2000, a ridiculous amount of the expert panel's time was spent debating the use of hyphens (-) vs. underscores (_) in element names and FieldML object identifier strings, at the behest of Poul Nielsen. He speculated (wildly) that if object identifiers contained hyphens (-), there existed the possibility for confusion with the arithmetic minus operator (-), although clearly the two look nothing alike. This might well occur if applications allowed expressions like (extra space added for clarity)

mesh-1  -  element-5

It was countered that the user was perfectly within their rights to use underscores in object identifier strings if so desired, and if they were not allowed to use whitespace in object identifier strings (declared in a DTD as attribute type NMTOKEN), an application would clearly be able to use whitespace for clarity as in the above example. As a reminder the Nmtoken and Name types (which correspond to the NMTOKEN and ID attributes respectively) are defined in the XML 1.0 specification as

NameChar  ::= Letter | Digit | '.' | '-' | '_' | ':' |
              CombiningChar | Extender
Name      ::= (Letter | '_' | ':') (NameChar)*
Nmtoken   ::= (NameChar)+

As XML awards underscores and hyphens equivalent status, it would be inappropriate to restrict the user from using hyphens in object identifier strings via the FieldML specification. As the user would rarely see FieldML documents in their raw text form, the use of underscores or hyphens in element and attribute names would not affect their choice of separator in identifier strings. It comes down to a case of precedent; some examples of element naming taken from existing XML applications are given in Figure 1.

More discussion anticipated ...

More Ridiculous Time Wasting

On top of the previously described irrelevant discussion, David Bullivant had the temerity to suggest that global node indexing was required in order to efficiently process the traditional nodal description. Typically, an application implementing a nodal system would want to be able to store a field as a vector of nodal field values and field derivatives. In order to load and interpret this vector, the processor would have to maintain a mapping between the field node numbers and the application's own internal global node vector - a problem potentially expensive to solve in both time and storage.

Why did we not want global node indexing? The reason is best demonstrated using the example in Figure 2.. Given a mesh (in this case a single element) for which a field is defined with a particular basis (in this case bilinear), we wish to add an additional field to the problem which uses a different basis (biquadratic) with a different number and ordering of nodes within each element. Given that the position of nodes is purely a function of the basis chosen within each element, and that the basis is a property of the field, global node numbering, although convenient, is not appropriate within the theoretical framework on which FieldML is based.

Figure 2.Bilinear and biquadratic fields, each with different node numbering, defined over a single two-dimensional element.

So, after more time-wasting, the global node proposal was thrown out, although some applications claiming to implement the traditional nodal description method of FieldML may be released without full support.

Better Connectivity

The connectivity scheme proposed in the 20 January 2000 meeting minutes, based on <virtual-face>s has some limitations that are not solvable using that system. Consider, for example, the problems shown in Figure 3, where two elements of the same dimension (all elements in a region must have the same dimension) share a boundary which is not one dimension less than the element dimension.

Figure 3.Three problems where the boundaries between elements are of dimension less than a face.

Such problems are best solved using a patch-coordinate system that is continuous across inter-element connections, and mapping the element coordinates in each element to this patch-coordinate system. Whereas the <virtual-face> idea allowed the mapping of element face coordinate systems to each other, a patch coordinate system, which may be several dimensions higher than the element coordinate system, would allow for mapping of the full element coordinate system. This allows the mapping of local coordinate derivatives between elements.

The patch coordinate system can easily tackle any connectivity problems that could be handled by virtual faces, by creating a patch coordinate system with dimension equal to the element faces. Consider an adaption of the problem proposed in Figure 3 in the 20 January 2000 meeting minutes where the dimension of the elements has been reduced to two dimensions, as shown in Figure 4.

Figure 4.A sample mesh with three two-dimensional elements simply connected.

The XML document describing this mesh, shown in Figure 5 has hardly changed; <virtual-face> has changed to <patch-coordinate>, and an dimension attribute has been added so it is clear to the processing application what is being mapped to what.