Re: APPEL and the dataschema element

Sorry but this still doesn't make sense to me.

In the policy, you have

<DATA-GROUP base="">
           <DATA ref="#x.y.z"><CATEGORIES><online/></CATEGORIES></DATA>
</DATA-GROUP>


Whereas in the ruleset, you have

<DATA-GROUP>
<DATA ref="http://www.foo.bar/the/file/containing/the/policy.xml#x.y.z">
<CATEGORIES><online/></CATEGORIES>
</DATA>
etc. . . .
</DATA-GROUP>


**************

This will not match unless you "pre-filter" the policy to alter how it's
expressed from

<DATA-GROUP base="">
           <DATA ref="#x.y.z"><CATEGORIES><online/></CATEGORIES></DATA>
</DATA-GROUP>

to

<DATA-GROUP>
           <DATA
ref="http://www.foo.bar/the/file/containing/the/policy.xml#x.y.z"><CATEGORIE
S><online/></CATEGORIES></DATA>
</DATA-GROUP>

Also - something else you said is confusing me:

In the APPEL spec, the example is given of categories being expanded like
so:

      <appel:RULE behavior="block">
      <!-- This rule matches if an element from the
           "online" category has been requested -->

        <POLICY>
          <STATEMENT>
            <DATA-GROUP appel:connective="or">
              <DATA category="online"/>
            </DATA-GROUP>
          </STATEMENT>
        </POLICY>
      </appel:RULE> <appel:RULE behavior="block">
      <!-- Explicit representation of the rule on the left. -->

        <POLICY>
          <STATEMENT>
            <DATA-GROUP appel:connective="or">
              <DATA ref="#user.home.online.email"/>
              <DATA ref="#user.home.online.uri"/>
              <DATA ref="#user.business.online.email"/>
              <DATA ref="#user.business.online.uri"/>
              <DATA ref="#dynamic.cookies" category="online"/>
              <DATA ref="#dynamic.miscdata" category="online"/>
            </DATA-GROUP>
          </STATEMENT>
        </POLICY>
      </appel:RULE>



To me, this seems to be exactly analogous to what I wrote below (assuming
we're not referring to the base data schema, so there are not necessarily
any dynamic category elements which have to be assigned categories)

 <DATA-GROUP base="mycustomschema.xml" appel:connective="or">
        <DATA category="online"/>
      </DATA-GROUP>

------------>>>>

 <DATA-GROUP  appel:connective="or">
         <DATA ref="#x.y.z"/>
        <DATA ref="#x.y.w"/>
        <DATA ref="#a.b.c"/>
        <DATA ref="#a.b.e"/>
etc. . . .
      </DATA-GROUP>

Yet you say I need to expand the category only element - could you explain
what you meant.

Also - what does the specification have to say about whether the category of
an element should be expressed as a child element
(<categories><online></categories>) or an attribute? (<ref . . .
category="online">)

Thanks for all your help

Giles









----- Original Message -----
From: "Nikolaj Budzyn" <budzyn@ti.informatik.uni-kiel.de>
To: "Giles Hogben" <giles.hogben@jrc.it>; <www-p3p-dev@w3.org>
Sent: Monday, October 01, 2001 7:19 PM
Subject: Re: APPEL and the dataschema element


> > > > But this seems to cause a serious problem for the APPEL matching
> > algorithm
> > > > >
> > > > > Here is an example of what I mean:
> > > > >
> > > > > RULESET
> > > > > ========
> > > > >  <DATA-GROUP base="mycustomschema.xml" appel:connective="or">
> > > > >         <DATA category="online"/>
> > > > >       </DATA-GROUP>
> > > > >
> > > > > EVIDENCE
> > > > > ========
> <DATA-GROUP base="">
>
> > <DATA-GROUP base=""> because the problem is precisely
> > with embedded schemas - because they are now embedded above the policy
> > level, and so can't be expressed in APPEL.
>
> "" means the XML-document that contains (within a POLICIES element) the
> POLICY element, that represents the policy given into the rule evaluator.
> So "" (in the policy!) references the ONLY (custom) dataschema, that's
> contained within this XML-document (within a DATASCHEMA element,
> include in the POLICIES element.)
>
> > Specifically as to how it will solve the problem of the path to an
inline
> > schema ("") (which now can't be expressed in APPEL)
>
> If an XML-document at http://www.foo.bar/policies.xml contains a policy
> and a dataschema, you would have to write
> base="http://www.foo.bar/policies.xml" in the ruleset, to reference
> the dataschema from http://www.foo.bar/policies.xml.
> (Writing "" in the ruleset is non-sensical, as no ruleset may contain
> a dataschema.)
>
> > Take the previous example:
> >
> > RULESET
> > ========
> >  <DATA-GROUP base="mycustomschema.xml" appel:connective="or">
>
> base is supposed to be a full URI!
>
> >         <DATA category="online"/>
> >       </DATA-GROUP>
> >
>
> Note that in this ruleset, the base attribute is of no effect!
>
> > EVIDENCE
> > ========
> > <DATA-GROUP base="">
> >                 <DATA ref="#x.y.z"/>
> >         <DATA ref="#x.y.w"/>
> >         <DATA ref="#a.b.c"/>
> >         <DATA ref="#a.b.e"/>
> >       </DATA-GROUP>
> >
> >
> > After expansion on both sides would then be
> >
> > RULESET
> > ========
> >  <DATA-GROUP  appel:connective="or">
> >          <DATA ref="mycustomschema.xml#x.y.z"/>
>
> After the expansion, ref is supposed to be a full URI reference!
> Not only a file!
>
> >         <DATA ref="mycustomschema.xml#x.y.w"/>
> >         <DATA ref="mycustomschema.xml#a.b.c"/>
> >         <DATA ref="mycustomschema.xml#a.b.e"/>
> > etc. . . .
> >       </DATA-GROUP>
> >
> > EVIDENCE
> > ========
> > <DATA-GROUP  appel:connective="or">
> >              <DATA ref="#x.y.z"/>
>
> Nope. After the expansion, ref is something like
> "http://www.foo.bar/the/file/containing/the/policy.xml#x.y.z"!
>
> Moreover, you need to expand the category/ies!
>
> So you would end up with something like
>
> <DATA ref="http://www.foo.bar/the/file/containing/the/policy.xml#x.y.z">
> <CATEGORIES><online/></CATEGORIES>
> </DATA>
>
> >         <DATA ref="#x.y.w"/>
> >         <DATA ref="#a.b.c"/>
> >         <DATA ref="#a.b.e"/>
> >       </DATA-GROUP>
> >
> >
> > This still seems to produce a matching failure:
>
> If you do the expansion as I showed above,
> the ruleset matches the evidence!
>
> > Could you give me an idea of when are we likely to see the new
> > specification?
>
> About end of november, I guess. Not sure.
>
> >
> > Thanks
> >
>
> Welcome
>
> Nikolaj
>
>

Received on Monday, 1 October 2001 14:05:58 UTC