Hi Venu, I meant that this is required by DOM, but is not correct for XNI or SAX, and may not be correct for other XML APIs.
The description of getType for org.apache.xerces.xni.XMLAttributes states that: 'The attribute type is one of the strings "CDATA", "ID", "IDREF", "IDREFS", "NMTOKEN", "NMTOKENS", "ENTITY", "ENTITIES", or "NOTATION" (always in upper case). If the parser has not read a declaration for the attribute, or if the parser does not report attribute types, then it must return the value "CDATA" as stated in the XML 1.0 Recommentation clause 3.3.3, "Attribute-Value Normalization"). For an enumerated attribute that is not a notation, the parser will report the type as "NMTOKEN".' Returning null from the getType methods means that an attribute is absent or you've specified an index that is out of bounds. It would appear to me that XNI doesn't allow null to be returned for other reasons, and explicitly says that it should return "CDATA" if no declaration is present. This is why we don't check internally for null values. Unless we're opening up XNI to more changes, doing something else besides treating this as null everywhere, in my opinion, is the appropriate thing. Someone could always specify their own parser configuration, and if it behaves according to XNI, DOM won't get the null it was expecting. Also I believe the parser components should try to be API neutral where possible. If DOM needs null for undeclared attributes, then the pipeline should expose enough information for DOM to determine this value, rather than forcing this value within the internals. This may work for some requirements, but it becomes a bit of a mess when two or more APIs have conflicting requirements that are difficult (or impossible) to satisfy simultaneously. On Tue, 4 Nov 2003, Venu wrote: > Sorry i had missed checking in XMLAttributesImpl.java. > > As you already pointed out in [2]and [1] attribute type should be null > when declaration is not found .My intent is to change all the places in > xerces where type is referenced appropriately( eg : check for null , > etc.).If all feel this is not appropriate thing to do then provding a > variable as suggested is the easiest alternative. > Depending on the suggestions i would either goahead and make changes req > when a SAXParser is used or back out the current checkins. > > All please let us know your views at the earliest. > > Regards, > Venu --------------------------- Michael Glavassevich XML Parser Development IBM Toronto Lab E-mail: [EMAIL PROTECTED] E-mail: [EMAIL PROTECTED] --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
