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] | [Elist Home]


Subject: [xacml] My position on "typing"


Title: My position on "typing"

Colleagues - This is my last opportunity to state my position on "typing" before traveling for the vote.  So, here goes ...

I do not see the need to define different XML types for every legal combination of data-types in each function and predicate.  The approach taken by the authors of MathML seems perfectly satisfactory to me: define an XML type for each function and qualify it with an XML attribute for the data-type of its return value.  I think we should define the legal argument-data-type combinations and the corresponding function return value data-types in normative tables (somewhat as we do in v14).

Using this approach, the enforcement of legal data-type combinations would not be the job of schema validation, it would be the job of the HLL programmer, using the normative information in the specification.  This seems perfectly satisfactory to me.

I would be happy with collecting all the common characteristics of predicates and functions in the substitution-group heads of these elements.  I have a feeling we did this (and the idea of having predicate derive from function, which in-turn derived from a substitution group) in an earlier version, and ran into the same problems that Simon encountered.  So, I can't say definitively that this is the way to go until we actually do it (successfully).

On the topic of importing MathML, I have managed to do this.  The resulting MathML schema is large (~400kB).  Therefore, I like the idea of defining a subset of MathML ... Obviously, it is attractive to import the entire schema.  But, I see no danger in defining an appropriate profile of MathML. containing the following elements ...

Token Elements:
<cn> Content Number
<ci> Content Identifier

Basic Content Elements:
<apply> explicit application of a function to its argument
<reln> equation or relation
<fn> user-defined function
<declare> declaration

Arithmetic, Algebra and Logic:
<quotient/> division modulo base
<divide/> division
<max/> maximum
<min/> minimum
<minus/> subtraction
<plus/> addition
<rem/> remainder modulo base
<times/> multiplication
<and/> boolean and
<or/> boolean or
<not/> boolean not

Relations:
<eq/> equal
<neq/> not equal
<gt/> greater than
<lt/> less than
<geq/> greater than or equal
<leq/> less than or equal

Theory of Sets:
<union/> union or meet
<intersect/> intersection or join
<in/> is in, is a member
<notin/> is not in, is not a member
<subset/> is a subset


All the best.  Tim.

-----------------------------------------
Tim Moses
Tel: 613.270.3183



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


Powered by eList eXpress LLC