RE: [xacml] Time for MathML?

[Tim Moses <tim.moses@entrust.com>]

Title: RE: [xacml] Time for MathML?

Bill - I expect we can import the required subset of the DTD without modification.  I've never done this.  But, I would be surprised if it turns out to be difficult.  All the best.  Tim.

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

-----Original Message-----
From: bill parducci [mailto:bill@parducci.net]
Sent: Tuesday, June 25, 2002 9:47 AM
To: Tim Moses
Subject: Re: [xacml] Time for MathML?

do you think that we should generate the schema for the whole thing
(resubmit back to the owners?), or pull the parts we deem valuable, wrap
them in a schema and go from there?

b

Tim Moses wrote:
> 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
>