Hi Jeff, Discarding non-specified attributes is also the default behaviour of the DOM L3 LSerializer. This can be turned off by setting the "discard-default-content" parameter [1] to false.
Thanks. [1] http://www.w3.org/TR/2004/REC-DOM-Level-3-LS-20040407/load-save.html#parameter-discard-default-content Michael Glavassevich XML Parser Development IBM Toronto Lab E-mail: [EMAIL PROTECTED] E-mail: [EMAIL PROTECTED] [EMAIL PROTECTED] wrote on 05/15/2008 05:32:57 AM: > Michael, > > Thanks for the info. I confirmed, by modifying the ParserAPIUsage > sample, that indeed that defaulted attributes are inserted in the DOM > if they're not present in the instance document. (They're also > inserted if they are fixed.) > > It turned out that there was some pilot error involved in my initial > report -- I had omitted just one of the defaulted attributes from the > schema, which was enough to to break the deserialization into objects > and make it appear that the defaulted attributes weren't being > inserted. > > The result was confused further in tests that serialized and printed > the parsed document. The code for this (written 5 years ago) used the > old XmlSerializer class, which by default filters out "specified" > attributes (i.e. those supplied from fixed or default specs in either > DTD or XML Schema). Using identity XSLT transforms for serialization, > as I had done in the modified JAXP example, avoids this optimization > of the output. According to the source code, there is a way to turn > off the filtering in the old XmlSerializer class as well, but it's not > clear whether this is a good idea in general. > > Jeff > > > On Wed, May 14, 2008 at 4:28 AM, Michael Glavassevich > <[EMAIL PROTECTED]> wrote: > > Hi Jeff, > > > > Attributes defaulted from the schema are unconditionally added to the > > document by the schema validator. They should appear in the DOM returned by > > the parser. I just confirmed that this is working with the latest version > > (2.9.1) but don't recall that there was any issue with 2.8.1. Perhaps > > there's something you're doing that you haven't mentioned here. A snippet of > > your code might help. > > > > Thanks. > > > > Michael Glavassevich > > XML Parser Development > > IBM Toronto Lab > > E-mail: [EMAIL PROTECTED] > > E-mail: [EMAIL PROTECTED] > > > > Jeff Greif <[EMAIL PROTECTED]> wrote on 05/14/2008 04:53:08 AM: > > > >> Thanks for the suggestion. I knew about accessing the PSVI, but I don't > >> think it can easily be used to solve the particular issue I'm facing. > >> > >> I'm dealing with a custom object deserialization method in which the > >> deserialization code requires that a type attribute and a version > >> attribute be present on the elements that represent one of the objects > >> in the graph of objects being deserialized from the instance document. > >> The instance document was produced to be valid against an older version > >> of the schema which was missing these attributes. By providing a > >> "transitional" schema for validation, in which these attributes are > >> optional, but have default values, I had hoped to produce a DOM from the > >> instance documents with the attributes filled in suitably for passing to > >> the deserialization code, analogously to the way that default values > >> specified in a DTD are filled in to the DOM when validation against the > >> DTD is carried out.. That is, the hope was that > >> someElement.getAttributeNS(null, "theTypeAttribute") would produce the > >> default value for that attribute even though the attribute was not > >> present in the instance doc. If this can't be done, I will probably > >> have to preprocess the documents with XSLT. > >> > >> The PSVI information could be used as a fallback in the deserialization > >> code if getAttributeNS returns null, but this would adversely affect the > >> integrity of the application. I'd prefer to find a way to deal with the > >> problem before the parsed XML is passed to the deserializer. > >> > >> Jeff > >> > >> Nathan Beyer wrote: > >> > Check out the PSVI API [1] - Post-Schema-Validation-Infoset > >> > > >> > [1] http://xerces.apache.org/xerces2-j/faq-xs.html > >> > > >> > On Tue, May 13, 2008 at 2:56 PM, Jeff Greif > >> > <[EMAIL PROTECTED] <mailto:[EMAIL PROTECTED]>> > >> > wrote: > >> > > >> > How can the Xerces parser be directed to insert attributes, > >> > specified > >> > in XML Schema to have default values, into a DOM during parsing when > >> > the attributes are not present in the input source? Presumably > >> > schema-validation must be turned on, but apparently some other > >> > setting > >> > is needed. The default attribute values are supposed to be > >> > accessible > >> > in the infoset, but perhaps they're not actually inserted into the > >> > DOM? I'm using xerces 2.8.1. <http://2.8.1.> > >> > > >> > Also, if the values can be inserted into the DOM, will they be > >> > output > >> > if the DOM is serialized to a string or stream? > >> > > >> > Jeff > >> > > >> > > >> > --------------------------------------------------------------------- > >> > To unsubscribe, e-mail: [EMAIL PROTECTED] > >> > <mailto:[EMAIL PROTECTED]> > >> > For additional commands, e-mail: [EMAIL PROTECTED] > >> > <mailto:[EMAIL PROTECTED]> > >> > > >> > > >> > >> --------------------------------------------------------------------- > >> To unsubscribe, e-mail: [EMAIL PROTECTED] > >> For additional commands, e-mail: [EMAIL PROTECTED] > > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] >
