Dear Wiki user, You have subscribed to a wiki page or wiki category on "Xerces Wiki" for change notification.
The "gsoc_xs_override_proposal" page has been changed by uswick. http://wiki.apache.org/xerces/gsoc_xs_override_proposal?action=diff&rev1=31&rev2=32 -------------------------------------------------- . Other sub-compnents , the ”Duplicates Handler” and “Dependency Analyzer” would come in to support the actions executed by “Transformation Manager” . Duplicates handler would provide necessary logic needed to detect duplicates and would try to handle them gracefully. “Dependency Analyzer” is also an important component since it would handle various tasks such as calculating TargetSet’s [3] of respective override components , supporting decisions of Duplicate Handler (ie:- in circular cases of overrides/includes ), etc . <xs:override> Semantics Component as a whole would be dependent on XSD Handler and vices versa during different stages of schema processing , so that aforementioned tasks can be successfully completed and ultimately the grammar pool is constructed with new <override> schema semantics included . The <override> semanitcs Handler will also keep a connection to the “Override Component Registry” constructed in the initial phases (ie:-construct trees phase) of schema processing ,which would map different <override> components with respective schema Documents that are implicitly/explicitly be affected by them . + . Implementation of these components need to take into account cyclic dependencies which could occur in <override> transformations. As discussed in the beginning these scenarios occur when the overriding paths go through a cycle of dependencies (ie:- include's) ,since <override> sematics apply for included schemas. Each time “Transformation Manager” finds an included schama component it would transform that into a <override> component with "schemaLocation" being that of the included schema.However after applying necessary override transformations ,the respective <override> components(residing in overriding scheam) would be replaced by <include>s pointing to the overriden schemas. For example if schema A overrides B which includes C and C inturn overrides A , the transformations would happen as follows. A will include B' (transformed/overriden version of B) , B' includes C' (transformed/overriden version of C) , C' includes A' (transformed/overriden version of A with merged overrides of both A and C ) and also similarly A' incl. B'' ,B'' incl. C'' , C'' incl. A'' and so on. However at the point of including A' if “Transformation Manager” sees that it differes with A then it would handle name collisions via "”Duplicates Handler” logic. Otherwise it would continue to the point of including A'' , where it would be notified of a cyclic dependency via “Dependency Analyzer” and would stop processing the cycle and continue with the schema processing work that yet to be completed. + . Following is a very simplified data flow diagram indicating the general control flow of schema processing with the proposed <override> extension in place.As described earlier this shows how our proposed <override> Handler extension works with XSD Handler to produce desired schema grammer with necessary <override> sematics info applied. . . . {{http://farm5.static.flickr.com/4068/4486137116_4cb2ba4dc7_o.jpg}} --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
