[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Specialization of Attributes
Here's what I think that Erik wants: Given: programmertype specializes role role specializes audience A filter on "audience='javaprogrammer'" should match content marked "programmertype='javaprogrammer'" But consider the complete implications of this. If audience specializes props then "props='javaprogrammer'" will also match. This implies that ALL values live in a single namespace. direction="left" and politics="left" would collapse down to the same thing. Nor is it just a namespace issue. Remember that DITA treats two values in the same attribute (OR) differently than it does two values in different attributes (AND). With attribute specialization we have some kind of in-between world where attributes are kind-of in the same attribute and kind-of in different attributes. Michael's proposal is that from a matching point of view it is totally irrelevant that programmertype specializes role or that role specializes audience. He says that the specialization information might be used somehow but not by the standard matching algorithm. This seems too fuzzy to me and also dangerous in that it encourages people to use the undefined feature. When we come up for a meaning for it (perhaps based upon Erik's ideas) then it will be too late to redefine the behaviour. Better to outlaw it until we understand it. This would also go for generic attributes. I'm not even sure whether it is meaning to talk about properties as having an "is-a" relationship to other properties. Mainstream programming langauges certainly have no such concept. More often there is some kind of a "derived-from" relationship but these are typically quite complex. "Color" can be derived from "Red", "Green" and "Blue". Age can be derived from "Date born". But now we're into the semantic web, not DITA. Paul Prescod
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]