FpML Issues Tracker
closed
Minor
Always
Schema
hpegeron
mgratacos
Summary
FpML uses URI's to identify coding schemes, for example:
This means that the "full" meaning of a indentifier code is made up of the URI attribute (xsd:anyURI), plus the code itself (xsd:normalizedString).
Examining the XML Schema standards you will find that this combination of values already has a defined representation, made up of a single value of type xsd:QName.
Actually a xsd:QName is slightly more restrictive as it is made up of xsd:anyURI plus xsd:NCName, with the main difference being that a xsd:normalizedString allows spaces (and colons) whereas xsd:NCName does not (xsd:NCName is, in fact, derived from xsd:normalizedString).
If the identifiers commonly in use do contain spaces, then xsd:QName can not be used, otherwise xsd:QName has some benefits:
* Developers, and other users of the standard, may be familiar with existing XSD, reducing the learning required (although only slightly in this case).
* XML tools have built in standard support for QNames, so less custom development is required, resulting in simpler processing software.
* The Schema definition is a lot simpler, being only one line with no type definition required:
* As it is not a complex data type it does not have to be an element, and can be an attribute instead, helping simplify document instances.
* Where a scheme is used in multiple locations within a document it can reduce document size by declaring it at a higher level in the document.
This also demonstrates declaring as an attribute, which sometimes also allows you to collapse the containing element (if it is otherwise empty).
i.e. compare:
with:
Note, however, that using a QName does have some drawbacks:
* It is slightly more restrictive than xsd:normalizedString, which may need to be addressed (e.g. if codes commonly have spaces they may need to be replaces with underscores).
* It is a change to the current standard which may already have been implemented.
* A specific "default" namespace, like the default value for XxxxScheme, can not be defined; using an undefined namespace will cause a validation error.
You could use the same default namespace as the schema (i.e. http://www.fpml.org/2003/FpML-4-0), but this may not be desired.
Overall, I think that using QNames would be a consistent, standard way of supporting code identifiers in future version of the FpML schema and provide several benefits.
Notes:
mgratacos
08/19/05 8:30 am
Thank you for your proposal however the AWG does not feel that this represents an improvement over the current solution.
Firstly your example instance comparison is incorrect. The majority of FpML elements that use scheme values have define a default value for the associated URI. In most cases these default URIs are the market norm and are rarely overriden in an instance document. Hence your example instance …
… can actually contain just this …
.. although it would appear as the former *within* an application after XML parsing.
One of the motivations for the current design was its simplicity. For any scheme value an attrbute on the containing element will hold the qualifying URI. The code to process these values is therefore very simple, for example in C#
string value = element.InnerText;
string uri = element.Attr[“someScheme”].Value;
In your instance example (shown below) the value of the party Id after parsing would be something like ‘bic:REUTGB21XXX’. String manipulation would be needed to split the code portion from the namespace prefix and a tree walk is required to resolve the ‘bic’ prefix to the URI itself as it could be define on any parent element. The AWG contends that this requires more program code than the current approach.
Another issue here is that the interpretation of the value ‘bic:REUTGB21XXX’ may change if it is copied from one document to another, for example from a request message into a reponse message. If the response message uses the same prefix for a later version of the scheme or has allocated it to a completely different scheme then a renaming procedure is required. This was one of the reasons why we moved away from the ‘schemeDefault’ attributes on the FpML element in an earlier release.
The current use of spaces in some FpML code values is a historical legacy. Early versions of FpML used DTD based grammars which provided little validation capability. We would like to use the schema ‘token’ type consistently but this is not possible for some older schemes.
Another problem is your example is the use of attributes for business information. The FpML standard was always modelled that business data as element content. Whilst other standards (expecially those more concerned with real-time messaging) have adopted attributes for business data we remain convinced that the use of elements gives us more control over the structure of our model. FpML needs this control because the products it supports are themselves complex in nature.
Andrew Jacobs
Chair, FpML Architecture Working Group