xacml message
[Date Prev]
| [Thread Prev]
| [Thread Next]
| [Date Next]
--
[Date Index]
| [Thread Index]
| [Elist Home]
Subject: RE: [xacml] Time for MathML?
- From: Daniel Engovatov <dengovatov@crosslogix.com>
- To: 'Tim Moses' <tim.moses@entrust.com>, 'XACML' <xacml@lists.oasis-open.org>
- Date: Mon, 24 Jun 2002 14:37:29 -0700
Title: 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..
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