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: RE: [xacml] My position on "typing"


Title: RE: [xacml] My position on "typing"

..I am still working on sample schema - in the mean time some thoughts...

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

Except for the fact that arithmetic operations on different data types will return different types - so you can not just define +(int, int) and +(float, float) - I still think that this should be two different declarations.  Reason - if you define a function that takes an int but does not understand a float, you do not want to wait until compile time to perform all type checking/call resolution/conversion - that would kill your performance.  Of course, you wouldn't know if the data type is passed in, whether it would convert, but that we have no way of controlling.  In this case - it is still allowable to call add_float with int arguments - they just have to be convertable..

In such approach - normative tables would contain only the mandatory conversions that MUST be possible to perform (say xml:long to xacml:int)

I agree, that there is no need to enforce argument type with schema mechanisms - as it does not work completely - but I think we still want to allow the application to do it in "compile" time..

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

Bingo. Very much agree.


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


Can we just use this subset as a starting base - but define all in our name space - and, maybe, in the way I suggested above?  ;)


P.S. True story:  When Kunz bugged Tim Lee - in December 91, why would not they define a mark-up for math, http protocol was a "collaboration tool for high energy physics" anyway, answer was "But everybody will be using TeX for mark-up - who in his right mind will need SGML extensions beyond HTML??"  ;-)



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


Powered by eList eXpress LLC