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: 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 language.

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 a copy.)

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,

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