[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: RE: [xacml] Context attribute clarification
Seth I expect the proposal is actually in-line with your understanding. It is my attempt to describe it that is out of line. I think you are saying that, as far as the PDP is concerned, anything between <AttributeValue> tags is a single attribute (including any xml attribute of the <AttributeValue> element, itself). Whether the attribute is primitive or structured, it is the associated function that should validate the contents. In the structured case, it will need some private way of locating the schema, given the DataType URI. Here is the current definition: <xs:element name="AttributeValue" type="xacml-context:AttributeValueType"/> <xs:complexType name="AttributeValueType" mixed="true"> <xs:sequence> <xs:any namespace="##any" processContents="lax" minOccurs="0" maxOccurs="unbounded"/> </xs:sequence> <xs:anyAttribute namespace="##any" processContents="lax"/> </xs:complexType> An attribute value that is an unencapsulated sequence of elements is valid according to this definition. But, if we expect the function to schema-validate, doesn't this introduce a problem, because such a sequence is anonymous? My understanding is that the anyAttribute declaration does not REQUIRE the <AttributeValue> element to have an atribute, but it MAY have one or more. Awaiting your thoughts. All the best. Tim. -----Original Message----- From: Seth Proctor [mailto:Seth.Proctor@Sun.COM] Sent: Tuesday, March 02, 2004 12:11 PM To: Tim Moses Cc: 'XACML' Subject: Re: [xacml] Context attribute clarification Judging from the examples you provide, I guess I haven't been reading these changes to the spec carefully enough. Here's what I think should be happening... > In the first case, we have a multi-valued attribute of primitive type. > This is relatively straightforward. The data-type is defined in the > <Attribute> element. In this case, the <AttributeValue> element > SHOULD NOT have any xml attributes. > > <xacml-context:Attribute > AttributeId="urn:com:food:favouriteVegetables" > DataType="http://www.w3.org/2001/XMLSchema#string"> > <xacml-context:AttributeValue>Brocolli</xacml-context:AttributeValue> > <xacml-context:AttributeValue>Parsnip</xacml-context:AttributeValue> > </xacml-context:Attribute> > > A matching <SubjectAttributeDesignator> or <AttributeSelector> would > return a bag containing two strings. Agreed. There are two values, both of type string, both with the same identifier. This is the whole point of Rebekah's proposal: a simple mechanism so that we don't have to use the Attribute element twice. > In the second case, we have a multi-valued attribute of complex type. > > <xacml-context:Attribute xmlns:Food="urn:com:food" > AttributeId="Food:favouriteMeals" DataType="Food:Dish"> > <xacml-context:AttributeValue> > <Food:Dish BestSeason="Fall"> > <Food:Main>Potato pie</Food:Main> > <Food:Veg>Brocolli</Food:Veg> > </Food:Dish> > <Food:Dish BestSeason="Fall"> > <Food:Dessert>Apple pie</Food:Dessert> > <Food:Topping>Double Devon cream</Food:Topping> > </Food:Dish> > </xacml-context:AttributeValue> <xacml-context:AttributeValue> > <Food:Dish BestSeason="Spring"> > <Food:Main>Asparagus quiche</Food:Main> > <Food:Salad>Spinach</Food:Salad> > </Food:Dish> > <Food:Dish BestSeason="Spring"> > <Food:Dessert>Crème brulée</Food:Dessert> > </Food:Dish> > </xacml-context:AttributeValue> > </xacml-context:Attribute> > > A matching <SubjectAttributeDesignator> or <AttributeSelector> would > return a bag containing four <Food:Dish> elements. Here I don't agree. The example you give only has two AttributeValues. A designator or selector should therefore return a bag with two values in it. How exactly am I supposed to see 4 values here? More to the point, how is the processing code supposed to see 4 values? If this example really yields 4 values instead of 2, then this proposal is not just providing a convenient shorthand syntax, it is re-defining how we process attribute values. > In this case, the <Attribute> element DataType attribute contains the > QName of the attribute element. Additionally, the namespace has to be > declared. No. The Attribute element specifies the identifier for the datatype used. If this is a custom type, and the processing code knows how to deal with the identifier as a QName and resolve a namespace, that's ok, but that's unknown to the specification. > Conclusion: the DataType attribute of the <Attribute> element should > be required. If the <AttributeValue> is of primitive type, the > DataType attribute MUST contain the type identifier of the attribute > as a URI. Also, in this case, the xml attribute in the > <AttributeValue> element MUST be omitted. The DataType attribute is required now, and is always a URI. Has the proposal in question changed this? It should not. Also, I don't think I understand the last sentence here...there is no standard XML attribute for xacml-context:AttributeValue. Some of the confusion here, I think, is that the example is incorrect. The DataType in the Attribute should not be Food:Dish, it should be something like Food:Dishes. Either that or there should be 4 AttributeValue elements in the Attribute. Actually, I think that the correct way, given the current specification, is: <Attribute AttributeId="Food:favouriteMeals" DataType="Food:Dish"> <AttributeValue BestSeason="Fall"> <Food:Main>Potato pie</Food:Main> <Food:Veg>Brocolli</Food:Veg> </AttributeValue> <AttributeValue BestSeason="Fall"> <Food:Dessert>Apple pie</Food:Dessert> <Food:Topping>Double Devon cream</Food:Topping> </AttributeValue> ... </xacml-context:Attribute> > If the <AttributeValue> element has complex contents, then the > namespace MUST also be declared and it is RECOMMENDED that it be > declared in the <Attribute> element. Also, in this case, the DataType > attribute of the <Attribute> element MUST contain the QName of the > attribute element. The <AttributeValue> element may contain xml > attributes. Gah. Is this really what we're proposing? Why the addition of QNames? The DataType attribute has clear meaning right now. It's an identifier that specifies the datatype of the value(s). As an aside, I am seriously worried about this proposal. It was originally supposed to provide a simple syntactic shorthand for describing a collection of values that happen to have the same datatype and identifier. This should have been trivial to add. That it's taking this long, and that we're talking about how to handle QNames, namespaces, and complex content suggests to me that this proposal has become something much more complex. Could someone please post a complete list of changes for this proposal so we can understand exactly what has happened? > Is this consistent with everyone's thinking? All the best. Tim. Apparently not. Sorry :( Also, it's spelled "Broccoli" ... at least in this country :) seth
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]