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]

Reply via email to