Dear Wiki user, You have subscribed to a wiki page or wiki category on "Xerces Wiki" for change notification.
The "ishanjayawardena/scd_proposal" page has been changed by ishanjayawardena. http://wiki.apache.org/xerces/ishanjayawardena/scd_proposal?action=diff&rev1=4&rev2=5 -------------------------------------------------- Based on these two operations and the incomplete SCP resolving capability, we can suggest following essential operations for the SCP interface.<<BR>> {{{XSObjectList resolveSCP(String scp, XSModel schema, NamespaceContext nc)}}}<<BR>> - {{{XSObjectList resolveSCP(String scp, XSModel schema)}}}<<BR>> {{{XSObjectList resolveIncompleteSCP(String scp, XSObject component, NamespaceContext nc)}}}<<BR>> - {{{XSObjectList resolveIncompleteSCP(String scp, XSObject component)}}}<<BR>> {{{String getCanonicalSCP(XSObject component, XSModel schema, NamespaceContext nc)}}}<<BR>> - After considering time constraints applied on the project and the need for setting up more realistic and measurable objectives, I will only implement the first four methods and if time permits, I will also consider implementing the fifth method as well. But I have not mentioned any specific details about it in my project schedule.<<BR>> + After considering time constraints applied on the project and the need for setting up more realistic and measurable objectives, I will only implement the first two methods and if time permits, I will also consider implementing the third method as well. But I have not mentioned any specific details about it in my project schedule.<<BR>> The main components of the implementation are the SCP parser and the SCP evaluator which are going to be used extensively by the above methods. For example, in the first four methods, the parser parses either an SCP or an incomplete SCP and then this expression is processed by the evaluator to return a list of schema components in an XSObjectList.<<BR>> At the initial stage, the parser and the evaluator is implemented to support only XML schema 1.0 object model and the system would be easy to extend due to the loosely coupled nature of its design, to support XML schema 1.1 object model as well. As I believe, speed and efficiency are the two most critical factors that must be met to a higher possible degree because the introduction of this new feature must not degrade the existing performance of Xerces under any circumstances. However, initially more attention is given to design a solid API and to come up with a more modular, extendable and a loosely coupled design as I mentioned earlier.<<BR>> - The parser can be generated with an automatic code generation tool similar to JavaCC and, to write the evaluator, a good understanding of the XML Schema API[[#15|[15] ]] and an understanding about how to navigate and XSModel is required. The SCD W3C specification defines the EBNF syntax for both SCD[[#16|[16] ]] and SCP[[#17|[17] ]] which can be used in the generation of the parser. However, it does not suggest any semantics for evaluating such expressions.<<BR>> + The parser can be generated with an automatic code generation tool similar to JavaCC and, to write the evaluator, a good understanding of the XML Schema API[[#15|[15] ]] and an understanding about how to navigate an XSModel is required. The SCD W3C specification defines the EBNF syntax for both SCD[[#16|[16] ]] and SCP[[#17|[17] ]] which can be used in the generation of the parser. However, it does not suggest any semantics for evaluating such expressions.<<BR>> == Deliverables == 1. Source code and necessary build files for the SCD parser and evaluator<<BR>> 2. Required patches if any<<BR>> --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
