OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.


Help: OASIS Mailing Lists Help | MarkMail Help

office-formula message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]

Subject: Re: [office-formula] "settlement The settlement date."


Dennis E. Hamilton wrote:
> I think there is a continuing misunderstanding on what those "lists of
> terms" are.  I would like us to clear that up before we get too deeply into
> massaging things.
> 1. Let's be specific and look at 5.12.2 ACCRINT, the first occurrence of
> "settlement" in the OpenFormula specification.
> 2. It appears to me that the list under Semantics is misplaced, since terms
> like "settlement date" are not being defined here but presumed to be defined
> elsewhere.  I suggest that the list 
> issue       The security's issue or dated date.
> first       The security's first interest date.
> settlement  The security's settlement date.
> coupon      The security's annual coupon rate.
> par         The security's par value, that is, the principal to be paid at
> maturity.
> frequency   The number of coupon payments per year. 
> basis       The type of day-count basis to use; see section 3.10.6 
> would best be under the heading "Parameters" and placed either directly
> under the Syntax: entry or the Returns: entry, depending on which is the
> most readable in general.  The Semantics heading would not be moved (and
> more semantic detail is doubtless called for).
> 3. With this rearrangement, I trust that it is more clear that the phrases
> on the right are not definitions of the term-like words on the left.  They
> are phrases for the nature of the value that is to be supplied to the
> function for the so-identified parameter.  (Cf. the Syntax: line.)  The use
> of italic text here is also a clue that these are not ordinary uses of words
> as (even-specialized) terms and nomenclature.  
> 4. I think it is a mistake to view the parameter names themselves as
> anything but symbolic labels for the parameter value that goes in a
> particular place in the syntax for use of the function in a formula.  For
> example, systematically replacing occurrence of the ACCRINT parameter names
> with I, F, S, C, P, F, and B, respectively, in the syntax and in the list
> specifying what the parameter values represent would change nothing.  The
> right-hand phrases in the list of the parameters would be unchanged however.
> [The use of the simpler parameter symbols is actually more-useful for
> transposition of the OpenFormula specification into another language, since
> translators would know *not* to translate those symbols.]
What do you think a "parameter value" for a "symbolic label" is if it 
isn't a "definition" of that label? Just curious.

Besides, your post misses the more important point that no matter what 
you call the left hand terms or even if they are symbols, we have not 
been consistent in specifying their semantics. Or at least that is what 
the spreadsheet I am constructing is designed to help members of the SC 
> 5. Being more precise about how "settlement date" is to be understood goes
> elsewhere, perhaps in the Semantics or in a preceding section of common
> terms used in the description of these financial functions.  There is a lot
> more that could be in the Semantics section about what these parameters
> represent and how they are calculated with.
Yes, there are all sorts of things we could define. What I am hoping we 
can focus on are things that are mentioned now in the draft and getting 
those defined. There may be others that need to be added but I would be 
happy just to enumerate all the known cases in the current draft.
>  - Dennis
> 6. It would probably be very helpful to specify how this layout works and
> what the parts are in Chapter 1, either as a subsection of 1.2 or a section
> following 1.2, although I can understand why it is thought to fit the
> narrative in flow in 5.2.  The use of typographical distinctions should be
> explained as well.
> 7. I notice that some of the parameter types are shown in italic text in the
> Syntax prototype, and some are not.  It would be useful to use italic text
> only for the parameters and use regular (Capitalized) text for the name of a
> parameter's data type.
Both of these are consistency of presentation issues as well as making 
the conventions explicit.
> 8. I also note that one could omit "Calculates" altogether from the Summary:
> phrase.  
> 9. With regard to the Returns: entry, one could say "Currency value of the
> accrued interest" (and "accrued interest" needs to be defined more precisely
> as well, elsewhere, of course).  
Well, the Summary section raises an interesting question. If the general 
statement in the summary section conflicts with the syntax or the 
formula under semantics, which one controls?

Example: CUMIPMT Where the syntax reports:

> CUMIPMT( /Number/ rate ; /Number/ periods ; /Number/ value ; /Integer/ 
> start ; /Integer/ end ; /Integer/ type )
Whereas the formula that appears under Semantics appears to be a 
summation function that has as its input another OpenFormula function, 
IPMT, which has the parameters that are listed for CUMIPMT.
> 10. There are some technical details that need to be examined as well.  For
> example, if the accrued interest is returned as a value of Currency type,
> then it should probably be Currency par, not Number par.  There are also
> many factors revealed in the test cases that should be explicit in the
> semantics.  The test cases should not be necessary for determining what the
> rule of calculation is.
> 11. There is also a problem of taking an exemplary use of this calculation
> as the definition of it.  ACCRINT works for any fixed principal amount for
> which fixed-interest payments are made at periodic intervals between two
> calendar dates (and particular treatment of basis and edge cases).  It is
> not necessary to speak of securities, par value, and other terms specific to
> particular securities-industry contexts.  One might introduce a note
> concerning the exemplary use for those wondering what an application of
> ACCRINT might be, but it would be great for that not being definitional.  If
> we make it definitional we run into problems with the calculation being done
> differently in different situations and rules of accounting and trading in
> securities.  We should define what the OpenFormula ACCRINT function is so
> that it can be calculated consistently across multiple implementations.  It
> is the responsibility of others to know when that specific calculation is
> appropriate in a given financial activity.
In general, yes. I suspect there are some "traditional" functions that 
qualify as what Fowler would call "sturdy indefensibles." Wrong but have 
been wrong so long that we are justified in codifying those functions. I 
suspect some of the TBill stuff falls into that category.

Hope you are having a great day!

> -----Original Message-----
> From: Patrick Durusau [mailto:patrick@durusau.net] 
> http://lists.oasis-open.org/archives/office-formula/200912/msg00121.html
> Sent: Tuesday, December 22, 2009 12:48
> To: office-formula@lists.oasis-open.org
> Subject: [office-formula] "settlement The settlement date."
> Greetings!
> Even assuming (perhaps incorrectly) a uniform semantic:
> "settlement The settlement date."
> is meaningless.
> Standards are about *defining* semantics, for good or ill.
> Perhaps, "... to boldly define where no one has dared to define 
> before....." ;-)
> Suggestions for a definition?
> Hope everyone is having a great day!
> Patrick

Patrick Durusau
Chair, V1 - US TAG to JTC 1/SC 34
Convener, JTC 1/SC 34/WG 3 (Topic Maps)
Editor, OpenDocument Format TC (OASIS), Project Editor ISO/IEC 26300
Co-Editor, ISO/IEC 13250-1, 13250-5 (Topic Maps)

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]