Hi Mukul, First of all, thank you for your feedback and all the suggestions.
On 10/3/10, Mukul Gandhi <[email protected]> wrote: > Hi Ishan, > I'm not sure if I am the right person to comment on this (but > feeling to do so since other folks at Xerces developer's team seem to > be tied up :) > > I really wish following points to be addressed for Xerces SCD > implementation: > > 1. Since Xerces XSModel is not an XSObject, can't we create a SCD root > object on top of Xerces XSObject -- or may be an implementation above > XSModel (something like following): > > interface SCDModel extends XSObject { > ... > } > > or may be SCDModel extends XSModel > > I'm not sure now, that which of above is more correct to be followed > for Xerces SCD implementation. > > I remember to have mentioned this a while ago on this list. I'm not > sure if Sandy saw any constraints to have them implemented. Or if you > discussed this with Sandy (perhaps you were short of time :( > I am also now looking into this and trying to come up with a better design. I will suggest a design as soon as I can. Then you can give your comments on it and we can then produce a much better implementation. I think earlier, Sandy had an idea about modifying XSModel to implement the XSObject interface. But I'm not sure if he's working on that right now. May be he will say something about that. > I think ability to map a lexical SCD pattern like /xx/yy to an object > path within XSModel tree is really an important use-case for SCD, and > must be implemented to consider an SCD implementation complete. > What do you mean by this? Can you explain it a bit more? I would like to share some thoughts about the current implementation, in general. i.e. we always needed to conform to the spec and implemented SCD exactly according to it even if we knew that the spec had errors at some points. Therefore the current implementation is completely spec compliant even if it doesn't do the right thing for some inputs. Currently, for some types of SCDs(i.e the (non normative)example SCDs given in the spec itself) there is a slight difference between the "expected results"(i.e. the results mentioned the spec) and the actual results. What sandy suggested as a solution was to document all these behaviors properly and rework our implementation whenever the spec fixes its bugs. > 2. I think it would be nice, if someone (perhaps you ...) can create > few use-cases for Xerces SCD implementation (kind of multiple > test-cases) and share with us. This would help us to learn about SCD > better, and what all things it can achieve. I think this will give > Xerces folks more motivation to learn about SCD (since it is a > relatively new language than say, XML Schema). > I will do that, but the results would be some what doubtful (or may even be incorrect) due to the current behavior of the resolver, as I explained earlier. > > AM, Ishan Jayawardena <[email protected]> wrote: >> Hi, >> I thought of reminding you about the work I did during the summer of >> code program. Sandy has already committed the SCD work to the schema >> 1.1 branch[0]. Also I wrote a JUnit test for it and I have attached it >> with this. If you have any concern, please let me know. Looking >> forward to have any comment or suggestion. >> >> [0] >> http://svn.apache.org/viewvc/xerces/java/branches/xml-schema-1.1-dev/src/org/apache/xerces/impl/scd/ >> >> Thanks. > > > > -- > Regards, > Mukul Gandhi > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [email protected] > For additional commands, e-mail: [email protected] > > -- Best Regards, Ishan Jayawardena. --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
