OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

cgmo-webcgm message

[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]