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] Time for MathML?


Title: Time for MathML?
Colleagues - One of the reasons for rejecting MathML, originally, was that it is so old that it is only defined in DTD, not XML schema.  This is probably not a strong reason.  Notice that MathML incorporates an explicit typing scheme, in which the <cn> and <ci> elements carry an optional "type" attribute.  One way to address Daniel's concern about partial inclusion is to adopt MathML in its entirely, including definite integrals.  However, I believe we can fairly readily list the parts of MathML that are useful in an access-control setting.  We have to make this list anyway, if we are to define our own set of types, functions and relations.  All the best.  Tim.
 

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

 
-----Original Message-----
From: Daniel Engovatov [mailto:dengovatov@crosslogix.com]
Sent: Monday, June 24, 2002 5:37 PM
To: 'Tim Moses'; 'XACML'
Subject: RE: [xacml] Time for MathML?

It is definitely is worth taking look at - but I would hesitate to suggest basing XACML standard on a standard that we do not support in its entirety. It will just add confusion..
 
That is the same issue I have with using XML mechanisms for type checking - if it is not 100% sufficient, then having it just adds complexity.
 
One proposal on data types: Why do not we define separate XACML data types (like xacml:integer, xacml:date) and require that any compliant application should provide implicit unique conversion to this data types from any XML schema data types.  That would have the advantage, that the implementation may define this data type internal representation broad enough, so it can accommodate some future, or custom data types, that can not be uniquely transferred to any particular XML schema data type.  It will also make for a more compact core schema.  
 
 
unrelated rant..
..Anecdote from my past experience - we had to define data interchange format for a very large future satellite experiment.  Some folks came up with a bright idea of using schema capabilities to enforce good structure (from physics prospective) of the event - needless to say they are still struggling to have one fully compliant data tool off the ground..  I feel we in a bit of the same mode - trying to enforce policy consistency, with XML capabilities.. not sure if it is worth trying..
 
-----Original Message-----
From: Tim Moses [mailto:tim.moses@entrust.com]
Sent: Monday, June 24, 2002 2:22 PM
To: 'XACML'
Subject: [xacml] Time for MathML?

Colleagues - Given the recent direction of our discussions, should we reconsider the suitability of MathML to our purposes?  Take a look at this link ...

http://www.w3.org/TR/REC-MathML/chap4_1.html

MathML defines a tag <reln> that would serve as our <Predicate>.  It defines a tag <apply> that would serve as our <Function>.  It defines a tag <cn> that would serve as our <Attribute> and a tag <ci> that (in conjunction with the <declare> tag) would serve as our <AttributeDesignator>.

Any thoughts?  Is this worth re-examining?  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