This is an archived snapshot of W3C's public bugzilla bug tracker, decommissioned in April 2019. Please see the home page for more details.
This relates to http://www.w3.org/Bugs/Public/show_bug.cgi?id=2630 as a result of which the XDM spec contains a paragraph in section 6.2.4 saying [Schema Part 1] also permits an element with mixed content to take a default or fixed value (which will always be a simple value), but at the time of this writing it is unclear how such a defaulted value is represented in the PSVI. Implementations therefore may represent such a default value by creating a text node, but are not required to do so. As a result of decisions by the Schema WG: see http://lists.w3.org/Archives/Member/w3c-xml-query-wg/2007Nov/0085.html it appears that the above paragraph can now be deleted. (However, before publishing our erratum, it would be a good idea to see which XML Schema revisions or errata actually fix the original problem.)
Note, at the time of writing bug #2632 contains no published resolution. We should hold on issuing an XDM erratum until the promised clarification to the XML Schema specification has been published.
To claify, it seems that we are stating the default value is NOT present in PSVI. What does this imply to an implementation that has supplied default value as text node in PSVI ?
Responding to comment 2: if the draft erratum for XSD 1.0 is eventually accepted, it does indeed make clear (in its current form) that no new character information items are added to empty elements with a declared default or fixed value. In the case of elements with simple content, the default is used to populate the [schema normalized value], but mixed-content elements don't have a [schema normalized value]. (They could, but as XSD 1.0 and 1.1 are currently specified, they don't.) The effect is essentially that a default value supplied for an element with mixed content doesn't seem to have much effect. (That may be a sign that the decision made by the Schema WG is a bad one and that QT should push back against it. I don't know.) If I were responsible for a processor that did supply default values for such elements, I would (a) plan to make the newly-clarified behavior an option for my users and (b) describe the existing behavior as a non-standard method of building the XDM instance, which supplies a value from the [schema default] property of the PSVI under certain conditions (specifically, when the element has no character information item children, and a [schema default] property is given -- if you ONLY supply the default value when the type is a complex type with complex content, then add also 'and if no [schema normalized value] is present in the PSVI for the element). But I am speaking only for myself.
Migrated issue to XDM 3.1 and resolved it per WG decision of 2014-04-29.