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=25&rev2=26 -------------------------------------------------- . . {{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 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. + . . 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> Handler 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 [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 . + . 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 . - . 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. + . 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 with necessary <override> info applied. . . . {{http://farm5.static.flickr.com/4068/4486137116_4cb2ba4dc7_o.jpg}} . . == Things I have Done So far == - . Since this project is about implementing a XMLSchema 1.1 specification construct , I had to go through this specification docs several times to understand the exact structure and semantics of the component I’m going to implement which I think is of vital importance when it comes to the design and implementation. Previous discussions (that has happened in Xerces-j-dev mail archives) about this xs:override support , online articles and tutorials also helped a lot in this cause. I also interacted with Xerces mailing list (especially with my mentor) to clarify critical points and implementation details. Since knowing Xerces and it’s internal framework(XNI) is obviously essential for the implementation I had to dig into various documentation, API information ,samples , regarding Xerces Design,architecture and especially XML schema processing. I did download the source code of Xerces2-j from trunk and build the code inorder to try and test out some samples to get a hang on the flow of things related to schema loading and processing.Running through several samples (xs.QuerryXS ,xni.GrammerBuilder, jaxp.SourceValidator, xni samples,etc) and debugging them , really gave me a good inisght into to Xerces framework... + . Since this project is about implementing a XMLSchema 1.1 specification construct , I had to go through this specification docs several times to understand the exact structure and semantics of the component I’m going to implement which I think is of vital importance when it comes to the design and implementation. Previous discussions (that has happened in Xerces-j-dev mail archives) about this xs:override support , online articles and tutorials also helped a lot in this cause. I also interacted with Xerces mailing list (especially with my mentor) to clarify critical points and implementation details. Since knowing Xerces and it’s internal framework(XNI) is obviously essential for the implementation I had to dig into various documentation, API information ,samples , regarding Xerces Design,architecture and especially XML schema processing. I did download the source code of Xerces2-j from trunk and build the code inorder to try and test out some samples to get a hang on the flow of things related to schema loading and processing.Running through several samples (xs.QuerryXS ,xni.GrammerBuilder, jaxp.SourceValidator, xni samples,etc) and debugging them , really gave me a good inisght into to Xerces framework. I also went through XML schema processing classes available in org.apache.xerces.impl.xs package to get a thorough understanding on exisiting schema processing framework and especially on how <redefine> semantics are applied to schema documents which is in some ways similar to <override> semantics. == Development Schedule == + . develop + ||<tablewidth="854px" tableheight="291px"width="200px" style="font-weight: bold; font-style: italic;">Time Schedule/Duration ||<style="font-weight: bold; font-style: italic;">Activity || ||March 18 - March 29 ||Initiate ideas ,discuss project details , get feed back on different aspects of the project,etc || ||March 29 - April 9 ||preparing project proposals and submission || ||April 26 ||GSoc Accepted student proposals announced by Google || ||April 26 - May 24 (Community Bonding Period) ||preparation on design aspects,architecture on xs:overide implementaion; preraration on various platform details (ie:-xerces architecture,schema processing,etc) ; prepare development environment; || - ||May 24 - July 12 ||creating necessary API's Start coding on xs:override implementation || + ||May 24 - July 12 ||creating/finalizing necessary API's ; Start coding on xs:override implementation || ||July 12- July 16 ||Mid term Evaluations - students and mentors submit evaluations || ||July 16 - August 9 ||start second phase of coding; integration of xs:override implementation phases (if any) ; writing tests to validate xs:override semantics; || ||August 9 - August 16 ||Final week of the project - final code submission on August 16th ; refine/review code ; finalizing documentaion; || --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
