[
https://issues.apache.org/jira/browse/XERCESJ-1391?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12741058#action_12741058
]
Mukul Gandhi commented on XERCESJ-1391:
---------------------------------------
Hi Hiranya,
Thanks for your comments. Kindly see my answers, below.
I noticed a lot of refactoring/reformatting stuff also in the patch some of
which are not really related to inheritable attributes feature. I think those
should go in as separate commits so we can keep track of the changes easily.
[mukul] frankly speaking, I partially agree to this. Always having separate
commits for refactoring, and reformatting is not always good. Doing a commit,
creates a new version in SVN. Ideally, a new SVN version should have some
significant and important addition to the code base.
But I agree, that major refactoring additions like creating new methods, doing
certain API changes, or say creating new classes, can go to a separate commit.
But I don't mind following a best practice, which is agreed upon by list
members :)
I realized that you have used a nested class named InheritableAttribute to keep
track of inherited attributes. You have stored them in a map keyed by element
information. I was wondering wouldn't it be sufficient to simply keep track of
the attribute index instead of an InheritableAttribute object? We can always
use the index to lookup the attributes list and get to the inherited attribute.
WDYT?
[mukul] The idea looks good. I'll check, if it's possible to do this, and would
make the changes.
(I haven't run this code yet. Will try that soon and let you know)
[mukul] I'll look forward to your comments, after you have run the code.
Regards,
Mukul
> XML Schema 1.1, inheritable attributes implementation
> -----------------------------------------------------
>
> Key: XERCESJ-1391
> URL: https://issues.apache.org/jira/browse/XERCESJ-1391
> Project: Xerces2-J
> Issue Type: New Feature
> Components: XML Schema 1.1 Structures
> Affects Versions: 2.9.1
> Reporter: Mukul Gandhi
> Attachments: inhr_attr_patch.txt, test.xml, test.xsd
>
>
> Hi all,
> I have written an implementation, for XML Schema 1.1 inheritable
> attributes. I am creating this JIRA issue for inheritable
> attributes, with a patch.
> I think, that a review of these changes would be good before we commit these
> changes to SVN server. This will help to ensure the correctness of
> implementation, and better quality of the code.
> I request, that this JIRA issue be assigned to the appropriate reviewer.
> Below are some implementation details, and a bit of design thinking I have in
> mind, for inherited attributes implementation.
> This patch has all the implementation for attribute traversal changes, and
> also some changes in XMLSchemaValidator.java
> (which are currently not finalized, but I plan to use these changes in CTA
> and assertions enhancements, for inheritable
> attributes).
> I am also attaching a dummy XML and XSD files, which I used to verify the
> attribute traversal changes. The attached XML is
> valid, for the given XSD, using the current XML Schema 1.1 code in SVN, plus
> this patch that I have written.
> As mentioned above, apart from attribute traversal changes (which are working
> fine, and tested at my end), the following code has been written in
> XMLSchemaValidator.java, which I plan to use to enhance CTA and assertions
> implementation, for inherited attributes:
> I have written a new method, saveInheritableAttributes(..) in
> XMLSchemaValidator.java, which I am invoking from,
> handleStartElement method.
> [1] CTA (conditional type assignment) changes
> I plan to enhance CTA implementation as following, to be able to use
> inherited attributes:
> In XMLSchemaValidator.java, I plan to modify the code fragment for CTA (the
> fragment, //process type alternatives). I'll add
> inherited attributes from the list, fInheritableAttrMap (using the element
> level information, which is the key to this map
> object) to the "attributes (of type XMLAttributes)" list.
> Rest of the code for CTA will remain same. The statement,
> if (test != null && test.evaluateTest(element, attributes)) {
> would use the new list of attributes (attributes, which are physically
> present on this element, plus the inherited attributes).
> After the CTA processing is complete (i.e after a type from CTA is assigned
> to the element), I'll remove the inherited
> attributes from the "attributes" list, so the original set of attributes is
> used by code after CTA processing.
> I think, these are all the changes that are required to enhance CTA
> implementation, to be able to use inherited attributes.
> [2] Assertion enhancements
> I plan to enhance assertions implementation as following, to be able to use
> inherited attributes:
> In the, handleStartElement method, I'll pass the inherited attributes as well
> to the assertions interface.
> To do this, I think following:
> addAssertsForEvaluation(element, attributes);
> would change to something like,
> addAssertsForEvaluation(element, attributes, inheritedattributes);
> In XMLAssertPsychopathImpl.java, I'll add the inherited attributes as well in
> the XDM tree to all descendant elements.
> I think, these changes would be sufficient, to implement inherited
> attributes, on assertions.
> I have just outlined the logic to enhance CTA and assertions, for inherited
> attributes. The final code, might look a bit
> different, than the specifics I have mentioned here.
> I would be thankful, if you could send me the feedback to this patch, and
> confirmation (and feedback) that CTA and assertions design changes, look ok.
> After I recieve the feedback to this patch, and to CTA and assertions design
> changes, I'll do the suggested modifications.
> I would appreciate, feedback from any member of the xerces-dev community, as
> well.
> Regards,
> Mukul
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
