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


Help: OASIS Mailing Lists Help | MarkMail Help

xacml message

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

Subject: Re: [xacml] Pseudo code standard?

Another historical note. In XACML 2.0 the combining algorithms were defined both in English language and in the same form of pseudo code as in the 3.0 spec, and which I am also using in the combining algorithms profile. In 2.0 there was no statement of which was normative, the English text or the pseudo code. In 3.0 we made the pseudo code normative. The new profile follows the same form as 3.0 core.

Best regards,

On 2014-03-18 15:57, Hal Lockhart wrote:
A historical note. In XACML 2.0 the higher order bag functions are defined using the Haskell language as well as English language text. The Haskell was removed in 3.0 mainly out of concern that the definitions might be or might later become incompatible with each, other creating ambiguity as to what the standard is.


-----Original Message-----
From: Erik Rissanen [mailto:erik@axiomatics.com]
Sent: Monday, March 10, 2014 6:03 AM
To: xacml@lists.oasis-open.org
Subject: [xacml] Pseudo code standard?


I am working on the various XACML profiles and I am reviewing the list
of comments from the TAB on the combining algorithms profile. Most of
them are pretty easy to fix, but there is one which I am uncertain what
to do about.


It says that we have not defined the syntax and semantics of the pseudo
code we use for the normative definition.

After some searching, I can think of several options:

1. Recode the algorithm in Java or some other commonly used programming

2. Use "Fortress", which is a real programming language which is made
to look like pseudo code, but also has a formal definition.

3. Reference a textbook, like "Introduction to Algorithms" (by Cormen,
Leiserson and Rivest), which defines a pseudo code language, and use
their syntax. (I used this book in my undergraduate studies, so I have

4. Switch to English instead. There should not be any complaints about
the language not being defined, but I think in practice this is going
to be more error prone than the undefined language we use today.

5. Use a formal language. I have been toying with the idea of defining
all of XACML in a formal language because of all the small issues and
clarification questions we have had over the years.

6. Define our own pseudo code format. I would rather not do this
because I am not a fan of re-inventing the wheel and I think this is
going to be error prone.

7. Keep the spec as it is.

Does anyone know of a best practice? Do other specs use pseudo code? If
we reference some externally defined language, are there process issues
to consider? Like for instance, is it ok to reference a commercial
programming language which might not be an open standard?

In many ways I like 7, because from a pragmatic point of view, I think
it will work fine as the spec is now. But I understand that by
principle we should use something more stringent.

I could write it in Java and I could also use 3 or look into 2.

Best regards,

To unsubscribe from this mail list, you must leave the OASIS TC that
generates this mail.  Follow this link to all your TCs in OASIS at:

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