Hi Pavani,
> There are 2 ways of handling <annotation> elements :
> 1. the traverser should check if there is an annotation element and if
there
is one call traverseAnnotationDecl(...) directly. This has to be done
if we wish the pass the annotation information to the application.
> 2. call checkContent(Element parent, Element firstChild, boolean isEmpty)
which checks if firstChild is an <annotation> element and if yes, calls
> traverseAnnotationDecl(firstChild, parentAttrs, isGlobal, schemaDoc)
> So, i believe the above specified situation -- multiple ID attrs... --
doesn't arise as long as the traversers don't try to do both #1 & #2. :-)
Right you are in this regard! Somehow I forgot there are two Element
parameters in checkContent. Yikes! But the problem with multiple ID
attributes being invalidly detected still will arise, except on the parent
element; this problem will arise inevitably if
XSAttributeChecker.checkAttributes is called more than once on any element
(as it is here since whoever's traversing the parent must have called this
method on the parent).
> The globalness check i have made is for the parent element to get its
attributes and pass them to traverseAnnotationDecl(...). I think this is
needed to get the attributes from the AttributeChecker.
> But i do have a doubt as to why we are passing the parent's attributes to
traverseAnnotationDecl(...). Please clarify.
>From 3.13.2 of the structures spec, describing the schema component
properties derived from the XML representation:
{attributes}
A sequence of attribute information items, namely those allowed by the
attribute wildcard in the type definition for the
<annotation>
item itself or for the enclosing items which correspond to the component
within which the annotation component is located.
For this reason I think we need to add a parameter for the caller to pass
in their attributes. Once traverseAnnotation actually returns something we
can add yet one more parameter to pass that back to the caller so that most
(if perhaps not all) of the traversers can still use this method. This
will require some modifications to the traversers, but since multiple calls
to checkAttributes(...) is a non-starter this seems to be the only
solution.
>> 3. I don't know how much you've looked into our error-reporting
>> infrastructure, but before he went on holiday Sandy spent a good bit of
>> time on this. Hence my feeling is that, whenever possible, we should use
> this infrastructure and throw real errors rather than putting lots of
>> revisits in our code.
>Yes, done.
Well, actually... I was thinking of the reportSchemaError method in the
XSDAbstractTraverser class. The reason for using this instead of
reportGenericSchemaError is that we can put the textual part of error
messages into a properties file which will make internationalization
infinitely easier if we ever need to go down that road. Also, the PSVI
requires that identifiers be attached to assessment outcomes; this Sandy
also built right into the error infrastructure. You can see how he did
this by looking in XSElementDecl.
In fact, in the medium term we need to root out all occurrences of
reportGenericSchemaError. This was even a priority in Xerces 1 but we
never quite finished.
So I hope you don't hate me too much :-), but I wonder if you'd be willing
to take another look at these points before I commit your code?
Thanks,
Neil
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
