[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: applyCompanionFile algorithm
Hi guys, Here's an attempt of putting into words the applyCompanionFile algorithm. It's not an easy exercise! Is this understandable to any one? I figure that it is going to take us a few passes... Question: How strict do we want to be with invalid companion file? The general algorithm for the applyCompanionFile method is the following: 1. Verify that root element is <webcgm>, else stop further processing and throw FILE_INVALID_ERR exception. 2. Process unknown attributes if any on root element, see Processing namespace attributes. 3. Process all child elements using a depth-first algorithm. More specific rules for processing namespace attributes are: 1. The target APS must be present in the CGM file, if that is not the case, all attributes of the current element are ignored. 2. If the attribute is not part of the base WebCGM DTD, it must be an extended namespace attribute, else the attribute is ignored. 3. An attribute that is already on the corresponding APS must be updated with the new attribute value. 4. In the case where an attribute with the same local name and namespace URI is already present on the APS, its prefix is changed to be the prefix part of the qualifiedName, and its value is changed to be the attribute value. If the attribute does not exist on the APS, the namespace attribute is appended onto the APS. More specific rules for processing child elements are: 1. The target APS (the parent element) must be present in the CGM file, if that is not the case, all child elements of the current element are ignored. 2. If the element is not part of the base WebCGM DTD, it must be an extended namespace element. Namespace elements and their attributes are appended at the end of the target's list of child elements. 3. Elements that do belong in the WebCGM DTD are processed as follows: i) namespace attributes are processed as specified above. ii) attributes relevant to this element, are updated on the APS. iii) other attributes are ignored. 4. If the element is a <linkuri>, the following rules apply: i) If one or more 'linkuri' attribute(s) exists on the parent element, they are deleted. (i.e., it is not possible to add links to already existing links, the companion file has to contain all the links to take part of the 'linkuri' APS attribute). ii) The attributes of the <linkuri> element are combined to create a single WebCGM 'linkuri' APS attribute (as defined in WebCGM 1.0) on the parent element. 5. If the element is a <bindById>, only namespace attributes and attributes relevant to the target APS type are added to the target (i.e., if the <bindById> has a 'screentip' attribute and the target APS is of type 'layer', the 'screentip' attribute will be ignored). 6. If the element is a <bindByName>, the user agent has to find all Application Structures that have a matching 'name' or 'layername' attribute. All found Application Structure are then subject to new attribute values (refer to the <bindById> description above). -- Benoit mailto:benoit@itedo.com
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]