Imported from previous forum
[ original email was from Stephen Pope - stephen.pope@ubs.com ]
Is there a (draft of a) RELAX NG specification for the FAST 1.2 proposal?
The proposal itself is certainly not normative and leaves much to the imagination, particularly with regards to the new , , and elements. Clearly, some of the attributes which in FAST 1.1 used to be associated with the field elements (i.e. , , etc.) have moved either to the new element, the new element, or have moved to the new non-field type elements( , , etc.)
All the provided examples indicate that a element is legal content for a element, but could it also be used within a element>?
Also, it is not clear how to evaluate dictionary=“type” and dictionary=“template” when used on an operator element contained by a type contained in a element. As there is (or may be) no element in the parentage of the element, we apparently need to search instead not within the element tree (e.g. DOM), but rather via the referring elements. However, what about searching for for the ns attribute that goes with a key attribute: should we search the parentage in the element tree, or via the references, or some combination of them since each could yield a possibly differing value.
By way of example:
Now, it seems pretty clear that the resulting actual dictionary “names” should be (assuming an obvious format for constructing them to follow the name matching rules):
template A field seq: type.ns2.AType
template A field string: template.ns2.ATemplate
template B field seq: type.ns3.BType
template B field string: template.ns3.BTemplate
however it is much less clear what the keys should become because I have not specified an ns attribute on the operators. If I follow the reference as for the dictionaries, then do I pick up the ns=“ns1” that appears in the element (and must, to correctly reference the ), or the ns attribute from the elements? On the other hand, if I strictly follow the element tree parentage, I would of course pick up the ns attribute from the instance.
Having a RELAX NG schema and a description of how to handle dictionary and key ns attributes with the new type definition elements would be most helpful!
My interest in FAST 1.2 lies purely in exploiting it for internal purposes; all the external instances of FAST I work with are of course still FAST 1.1 or deviations therefrom. So I am in fact free to make my own interpretations, but …
stephen
[ original email was from Stephen Pope - stephen.pope@ubs.com ]
My apologies, I missed a few closing /> sequences when I typed the example in by hand. Here it is corrected so it will at least parse.
And it seems that if my template processor essentially handles any occurrence of a element by replacing it with a unique copy of the content of the matching element, I at least get sensible (and useful) behavior, but I am not sure that this is the intent of what is described in the proposal.