471,089 Members | 1,548 Online
Bytes | Software Development & Data Engineering Community
Post +

Home Posts Topics Members FAQ

Join Bytes to post your question to a community of 471,089 software developers and data experts.

Retain default attribute values after XSD Validation?

In my app I'm validating an XML file against an XSD which contains several
attribute default value specifications. I'm performing the validation via an
xml document load() using a ValidatingXMLReader. After loading the document
(and validating it) I assume that the resulting doc will (as appropriate)
have elements with attributes set to their default values in those cases
where there was nothing specified in the input XML file.

However, when I serialize the resulting doc using its WriteContentTo method,
the default attributes are NOT represented in the XML output stream. Is this
expected behaviour and, if so, how can I arrange to retain these default
attribute values?

Thanks in advance,
Bill
Nov 12 '05 #1
2 3758
"Bill Cohagan" <bi**@teraXNOSPAMXquest.com> wrote in message news:uT**************@TK2MSFTNGP11.phx.gbl...
In my app I'm validating an XML file against an XSD which contains several
attribute default value specifications. : : when I serialize the resulting doc using its WriteContentTo method,
the default attributes are NOT represented in the XML output stream. Is this
expected behaviour and, if so, how can I arrange to retain these default
attribute values?


WriteContentTo( ) could have any of three motivations:

1.) It could generate an XML serialization preserving as much of the
original XML serialization as possible, including insignificant white
space and the quote characters delimiting each attribute value.

(I'd dismiss this as it imposes too heavy of a burden to maintain
knowledge of the original serialization format. The XML Infoset
is unconcerned with these minutia which it sees as irrelevant
artifacts of the serialization. XmlDocument is a model of the
Infoset.)

2.) It could generate XML that is canonically equivalent to the
original serialization format. This disregards irrelevant minutia,
such as the quantity of whitespace between attributes in an
element tag. It preserves those details of importance when
two XML documents must be compared for equivalence; which
has important applications in XML Encryption and XML Digital
Signatures.

3.) It could produce the Post Schema Validation Infoset (or PSVI),
if available. The PSVI contains value-added information from the
schema validation process, such as default attribute values, that
were not present in the original document. While additive, this
creates a document which is not equivalent to the original source,
and under some circumstances might be undesirable.

As one example of where producing the PSVI could be a mistake,
suppose I have an XML document with a child element, Account.
Account may have an attribute, MaxFDICInsuredBalance, defined
in the XML Schema as having the default value of $100,000.00.
Being a bank, I'll want to digitally sign the Account element to both
preserve its integrity (detect any alteration) and authenticate myself
(or my back-end process) as being the last person to modify it.

What happens if I schema-validate this digitally-signed document
in a ValidatingXmlReader and then pass it along to another process
that verifies the authenticity of the digital signature? 'Lo and behold,
should WriteContentTo( ) produce a serialization based on the PSVI
rather than one thats canonically equivalent to the original signed
document, the Account element has been tampered with!

Looking at it more closely, the explicit content of the Account element
would've changed were a WriteContentTo( ) to serialize the PSVI.
It would now contain the implied attribute value of $100,000.00 for
MaxFDICInsuredBalance, whereas the Account element was signed
when that wasn't present.

If WriteContentTo( ) did intend to serialize the document in a canonically
equivalent representation of its original content (rather than the serialize
the document's PSVI including default attribute nodes), I imagine it would
employ the IsDefault property of XmlReader to do so.

This nugget may suggest an answer to your second question, how to retain
the default attribute values?

Try subclassing ValidatingXmlReader and override the virtual IsDefault
property to always return false.

- - - KeepPsviDefAttrs.cs
using System.Xml;
public class MyValidatingXmlReader : ValidatingXmlReader {
public override bool IsDefault { get { return false; } }
}
- - -

Then use this MyValidatingXmlReader when loading the XmlDocument.
Whenever WriteContentTo( ) asks whether a given attribute node should
be serialized because it was added as a default value, you can direct
WriteContentTo( ) to ignore this distinction (serialize all attributes whether
they are default or not).
HTH,

Derek Harmon
Nov 12 '05 #2
Derek
Good summary of the problem -- and good solution as well. Overriding the
isDefault method solves the problem.

Thanks again!

Bill

"Derek Harmon" <lo*******@msn.com> wrote in message
news:uA****************@tk2msftngp13.phx.gbl...
"Bill Cohagan" <bi**@teraXNOSPAMXquest.com> wrote in message news:uT**************@TK2MSFTNGP11.phx.gbl...
In my app I'm validating an XML file against an XSD which contains several attribute default value specifications.

: :
when I serialize the resulting doc using its WriteContentTo method,
the default attributes are NOT represented in the XML output stream. Is this expected behaviour and, if so, how can I arrange to retain these default
attribute values?


WriteContentTo( ) could have any of three motivations:

1.) It could generate an XML serialization preserving as much of the
original XML serialization as possible, including insignificant white
space and the quote characters delimiting each attribute value.

(I'd dismiss this as it imposes too heavy of a burden to maintain
knowledge of the original serialization format. The XML Infoset
is unconcerned with these minutia which it sees as irrelevant
artifacts of the serialization. XmlDocument is a model of the
Infoset.)

2.) It could generate XML that is canonically equivalent to the
original serialization format. This disregards irrelevant minutia,
such as the quantity of whitespace between attributes in an
element tag. It preserves those details of importance when
two XML documents must be compared for equivalence; which
has important applications in XML Encryption and XML Digital
Signatures.

3.) It could produce the Post Schema Validation Infoset (or PSVI),
if available. The PSVI contains value-added information from the
schema validation process, such as default attribute values, that
were not present in the original document. While additive, this
creates a document which is not equivalent to the original source,
and under some circumstances might be undesirable.

As one example of where producing the PSVI could be a mistake,
suppose I have an XML document with a child element, Account.
Account may have an attribute, MaxFDICInsuredBalance, defined
in the XML Schema as having the default value of $100,000.00.
Being a bank, I'll want to digitally sign the Account element to both
preserve its integrity (detect any alteration) and authenticate myself
(or my back-end process) as being the last person to modify it.

What happens if I schema-validate this digitally-signed document
in a ValidatingXmlReader and then pass it along to another process
that verifies the authenticity of the digital signature? 'Lo and behold,
should WriteContentTo( ) produce a serialization based on the PSVI
rather than one thats canonically equivalent to the original signed
document, the Account element has been tampered with!

Looking at it more closely, the explicit content of the Account element
would've changed were a WriteContentTo( ) to serialize the PSVI.
It would now contain the implied attribute value of $100,000.00 for
MaxFDICInsuredBalance, whereas the Account element was signed
when that wasn't present.

If WriteContentTo( ) did intend to serialize the document in a canonically
equivalent representation of its original content (rather than the

serialize the document's PSVI including default attribute nodes), I imagine it would
employ the IsDefault property of XmlReader to do so.

This nugget may suggest an answer to your second question, how to retain
the default attribute values?

Try subclassing ValidatingXmlReader and override the virtual IsDefault
property to always return false.

- - - KeepPsviDefAttrs.cs
using System.Xml;
public class MyValidatingXmlReader : ValidatingXmlReader {
public override bool IsDefault { get { return false; } }
}
- - -

Then use this MyValidatingXmlReader when loading the XmlDocument.
Whenever WriteContentTo( ) asks whether a given attribute node should
be serialized because it was added as a default value, you can direct
WriteContentTo( ) to ignore this distinction (serialize all attributes whether they are default or not).
HTH,

Derek Harmon

Nov 12 '05 #3

This discussion thread is closed

Replies have been disabled for this discussion.

Similar topics

4 posts views Thread by Lénaïc Huard | last post: by
44 posts views Thread by gregory.petrosyan | last post: by
3 posts views Thread by Gary Wessle | last post: by
1 post views Thread by Harinath | last post: by

By using Bytes.com and it's services, you agree to our Privacy Policy and Terms of Use.

To disable or enable advertisements and analytics tracking please visit the manage ads & tracking page.