FpML Issues Tracker

940: English version of shared-12 is ambiguous

June 10, 2009

closed

Minor

Have not tried

Validation Rules

Admin

None

Summary

The English version of shared-12 is: " shared-12 (Mandatory) English Description: Context: Document (complex type) For buyerPartyReference anywhere in the document, @href shall match the @id attribute of a party element or the @id attribute of a tradeSide element. "

The phrase "anywhere in the document" is ambiguous because "document" is not defined. Does it mean either of Possibility #1: //buyerPartyReference Possiblity #2: document()//buyerPartyReference

Possibility #1 should be rewritten as: " For any descendent buyerPartyReference, @href shall match the @id attribute of a party element or the @id attribute of a tradeSide element. " Note that Possibility #1 is different from today's text because it excludes nodes outside the context.

Possbility #2 is an error because it contradicts the context, by referring to a Document, which is outside the context.

Besides all of the above "match" should be replaced with equals, and the rest of the text standardized. Also "for any" should be replaced with "for every". Then it would read: " Every descendent buyerPartyReference/@href equals at least one of the trade/@id or the tradeSide/@id attributes." " the @id attribute of a party element or the @id attribute of a tradeSide element. "

Notes:

  • matthewdr

    07/28/09 1:19 pm

    Discussed at the VWG today. Agreed to use the phrase “descendant”. Irina agreed to implement.

  • mgratacos

    07/29/09 9:20 am

    After taking another look at this issue, I wonder whether the term ‘descendant’ is clear to a business analyst. Comparing the original and proposed new description, the original description seems easier to understand for someone that doesn’t know XPath and terms such as descendant, parent, etc.

    I thought the purpose of having the English description was supposed to keep a language that was understandable to a business analyst, even if there is some ambiguity in the language. That’s why we introduced the technical description, to resolve such ambiguities that may exist in the English description once an implementation of the rule is needed.

  • matthewdr

    07/29/09 11:26 am

    I took the view that:

    XPath Version – this is the precise definition for people who know XML, XSD, and XPath
    English Version – this is for people who know XML but not XPath
    Comment Version – this is for people who don’t know either XML or XPath but know derivatives

    We could substitute “descendant element” with “element within” for the English version.

  • mgratacos

    07/29/09 2:58 pm

    I have a different view on this:

    XPath Version – this is the precise definition for people who know XML, XSD, and XPath
    English Version – this is for people who don’t know either XML or XPath but know derivatives
    Comment Version – this includes any supplementary information to clarify the description or usage of the rule.

    If we substitute descendant element by element within, what’s the updated description?

    What about the following description?

    For every buyerPartyReference element, the buyerPartyReference/@href attribute equals at least one of the trade/@id or the tradeSide/@id attributes.

  • matthewdr

    07/29/09 3:06 pm

    Marc – nearly all the English versions of the rules require knowledge of XML or basic XPath. If we followed your view then every rule would need to be rewritten to remove any reference to XML. To eliminate the need to know XML we would have to remove terms such as “element”, “attribute”, “/”, “@”, etc, from all the English descriptions.

    Your definition redefined the English version to be what the Comment is now. What would happen to the current English definition of the rule in your scenario? The curren English definition doesn’t fit in any of your three categories.

  • mgratacos

    07/29/09 3:36 pm

    Matthew – You are right. My view of English is too strict. I think a business analyst may know XML and basic XPath so “element”, “attribute”, “/”, “@”, which would fit the current English description but descendant, sibling, parent,…isn’t this too much?

  • matthewdr

    07/29/09 4:23 pm

    The precise definition of “descendant”, “sibling”, “parent” I would agree are too mcuh. But these are also the informal English terms that would likely be used by a non-technical person to describe the layout of the data. I believe they are guessable by an English speaker who doesn’t know what they mean.

  • mgratacos

    08/11/09 1:45 pm

    Val WG:

    Implementation is pending.

  • matthew

    08/11/09 1:46 pm

    Discussed at the VWG. Marc agreed we should complete this.

  • mgratacos

    10/27/09 6:01 pm

    This has been committed to the trunk and 5.0 branch.

  • Leave an update

    You must be logged in to post an update.