Subject: RE: [Geopriv] common-policy update

From: "Thomson, Martin" <[email-masked]>
Date: Thu, 13 Oct 2005 04:12:56 -0500

Hi Jari,

I hope that by now people realise that the xsi pieces are only in those example files to help with validation in the testing phase.  That is how I validate documents, but I would never expect to see them in a published document.  I think that you will find that Hannes has not copied them into the document.

I really appreciate you putting the validation online, that should be a great help to those who don't want to go to the effort that it takes to install your own.

With regards to the type stuff, are you suggesting that common-policy only define types (<complexType name="actionType">) so that using specifications can "include" common-policy to get the basic structures into their namespace?  Another example: PIDF-LO does this with the ...:basicPolicy element.

Cheers,
Martin

-----Original Message-----
From: [email-masked] on behalf of Jari Urpalainen
Sent: Thu 10/13/2005 3:02 AM
To: ext Tschofenig, Hannes
Cc: [email-masked]
Subject: Re: [Geopriv] common-policy update
 
<snip>

Great, looks good and definitely better. I have put up an online w3c 
schema validation tool at <http://validate.openlaboratory.net/> which is 
based on Xerces C++ library, feel free to use it (and yes your examples 
validate).  I'll add some schema related comments (I'll agree with most 
of the Martin's concerns as well): first I'd like to remove all 
instances of xsi:schemaLocation hints (and corresponding ns 
declarations) from the example instance docs. Secondly, I see 
common-policy as a framework which defines a necessary part of the whole 
authorization policy. So e.g. without actual <actions> or 
<transformations> you can certainly identify several <rules> for an 
identity, but you can't do much without  those  actions. So I'd prefer 
that common-policy would not specify any content-type and the schema 
would only define these types (what it currently has), i.e. 
presence-auth would include these common-policy types and it would 
define the content-type with all of these action/transformation stuff. 
This would mean in practice the same model that partial-pidf format and 
xml-patch-ops are using. We would then avoid having one unnecessary ns 
declaration and what's more, a more consistent content-type usage.
thanks,
Jari

_______________________________________________
Geopriv mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/geopriv

------------------------------------------------------------------------------------------------
This message is for the designated recipient only and may
contain privileged, proprietary, or otherwise private information.  
If you have received it in error, please notify the sender
immediately and delete the original.  Any unauthorized use of
this email is prohibited.
------------------------------------------------------------------------------------------------
[mf2]

_______________________________________________
Geopriv mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/geopriv

---

From: Jari Urpalainen <[email-masked]>
Date: Thu, 13 Oct 2005 13:53:11 +0300

>I hope that by now people realise that the xsi pieces are only in those example files to help with validation in the testing phase.  That is how I validate documents, but I would never expect to see…
Good, anyway this has been my "never-ending" complaint...

>I really appreciate you putting the validation online, that should be a great help to those who don't want to go to the effort that it takes to install your own.
And even if you have one, it's better to have alternatives, e.g. UPA 
constraint is not necessarily checked by every tool. (this is not to say 
that I like this schema language, there are better specs and tools 
available ...)

>With regards to the type stuff, are you suggesting that common-policy only define types (<complexType name="actionType">) so that using specifications can "include" common-policy to get the basic st…
yes pidf-lo seems to be importing basicPolicy. What I have in mind is 
however, that you would <xs:include> common-policy schema to e.g. 
presence-policy. common-policy would not declare any targetNamespace at 
all. So common-policy elements would inherit the namespaces of the 
parent schema (e.g. presence policy). This has been referenced as a 
Chameleon namespace design. In the current model the same content-type 
can carry really different  kind of authorization policy. And in 
general, I'll prefer instance docs that have as little "noise" as 
possible (==the less ns declarations the better) .
thanks,
Jari