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=24&rev2=25 -------------------------------------------------- . . - . xs:override implementation intends to extend this functionality to implement <override> structure semantics. Implementation would include extending the phase #constructingTrees to include necessary mappings for override schema components (ie:-creating a fOverride2XSDMap , to map override elements with respective schema documents ). In general modification to this phase can closely be related to <redefine> implementation and would include necessary control paths as and when needed. However most challenging task would be in extending next two phases (in #buildGlobalNameRegistries and #traverseSchemas ) when implementing xs:ovserride semantics. These two phases include depth-first traversal of schema dependencies (ie:-when schema A includes B , A depends on B and vice versa) built in the first phase ,for building primary and subordinate registries on global components , and for travesrsing them for validation , respectively.These are obviously very important in Implementation of xs:override and will require to extend them approprately with much emphasis on design aspects. Main design/implementation areas are , + . xs:override implementation intends to extend this functionality to implement <override> structure semantics. Implementation would include extending the phase #constructingTrees to include necessary mappings for override schema components (ie:-creating a fOverride2XSDMap , to map override elements with respective schema documents ). In general modification to this phase can closely be related to <redefine> implementation and would include necessary control paths as and when needed. However most challenging task would be in extending next two phases (in #buildGlobalNameRegistries and #traverseSchemas ) when implementing xs:ovserride semantics. These two phases include depth-first traversal of schema dependencies (ie:-when schema A includes B , A depends on B and vice versa) built in the first phase ,for building primary and subordinate registries on global components , and for traversing them for validation , respectively.These are obviously very important in Implementation of xs:override and will require to extend them approprately with much emphasis on design aspects. Main design/implementation areas are , . . * extending XSDHandler#checkForDuplicateNames() - to include necessary control paths for <override> semantics ,detecting the scenarios where duplicate collisions can occur and flagginf these errors appropriately. - * implementing XSDHandler#renameOverriddenComponents(currentSchema,childComponent,componentType,oldName,newName) - renaming overridden components taking into consideration overriding of <includes> and merging <overriding> components on respective schema locations + * implementing XSDHandler#transformOverriddenComponents(currentSchema,childComponent,componentType,oldName,newName) - renaming/transforming overridden components taking into consideration overriding of <includes> and merging <overriding> components on respective schema locations * extending XSDHandler#traverseSchemas() and traversers( org.apache.xerces.impl.xs.traversers) - to traverse override schema components , and also to take into account the behavior of each individual travereser objects on the application of xs:override semantics. . . @@ -76, +76 @@ . . • org.apache.xerces.impl.xs.XSDDescription - keeps track of all information specific to XML Schema grammars. This can be used to indicate the Schema processor that the current schema document is overridden by another schema document - . . Additionally xs:override implementation may require quite a few new components/data structures to be added to org.apache.xerces.impl.xs package inorder to handle different scenarios regarding <override> semantics as was described in the beginning. + . . Additionally xs:override implementation may require quite a few new components/data structures to be added to org.apache.xerces.impl.xs package inorder to handle different scenarios regarding <override> semantics (ie:-implicit <override> semantics handling, etc) as was described in the beginning. . . @@ -84, +84 @@ . Following is an abstract level view on the implementation of xs:override semantics as an extension to the current XML schema processing framework. - . . {{http://farm3.static.flickr.com/2686/4485386948_abe7fa82cd_o.jpg}} + . . {{http://farm3.static.flickr.com/2803/4486137118_3aa3d2bb13_o.jpg}} - . . XSD handler is the main component responsible for schema processing for Xerces-j . After successful implementation, the proposed extension (xs:override Semantics Component) would seamlessly integrate into this current Schema processing framework so that <override> semantics can be applied on schema documents appropriately .The <xs:override> component has three main sub components , namely “Transformation Manager” , “Dependency Analyzer” and “Duplicates Handler” .The primary sub-component , “Transformation Manager” have the task of applying necessary preprocessing and also override transformations on the respective schema components on which override semantics will be applied .It executes a very critical phase of <override> semantics implementation and indeed would pave the way for the actual schema generation. + . . XSD handler is the main component responsible for schema processing for Xerces-j . After successful implementation, the proposed extension (xs:override Semantics Handler) would seamlessly integrate into this current Schema processing framework so that <override> semantics can be applied on schema documents appropriately .The <xs:override> component has three main sub components , namely “Transformation Manager” , “Dependency Analyzer” and “Duplicates Handler” .The primary sub-component , “Transformation Manager” have the task of applying necessary preprocessing and also override transformations on the respective schema components on which override semantics will be applied .It executes a very critical phase of <override> semantics implementation and indeed would pave the way for the actual schema generation. - . 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[] 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 component 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 . + . 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 component 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 . - . Following is a very simplified data flow diagram indicating the general control flow of schema processing with the proposed <override> extension in place. + . 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> semantics component works with XSD Handler to produce desired schema grammer as and when needed. - . . {{http://farm5.static.flickr.com/4019/4485386942_2fce50a60d_o.jpg}} + . . . {{http://farm5.static.flickr.com/4068/4486137116_4cb2ba4dc7_o.jpg}} . . --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
