strategies for making elements unique

[Lisa]

I have to work with an existing xml where there is a root element and all
other elements are children of the root (in other words there is no nesting
or hierarchy), e.g.
<myroot>
<A>adata</A>
<B>bdata</B>
<C>cdata</C>
<A>otheradata</A>
</myroot>

Unfortunately there are a lot of rules for the elements, such as choices
(e.g. A or B), groups which are mandatory or optional or repetitive, etc. and
the elements can be used in various different groups. It is possible to write
a schema which validates this accurately, so creating such xml and validating
it is fine.
However, when receiving such data from somebody else, I would greatly
appreciate if the parser could actually let me know that it has e.g. found
<A> in the first (maybe optional) group. I have looked at various strategies:
1. use a default attribute which gives extra information. doesn't work,
because when compiling the schema, elements of same hierarchy level and same
name may not have different default attributes.
2. use an id. Seems to be the same problem: id is an attribute. also I
haven't really found out how to work with ids.
3. use unhandledattributes. this would be a great method, if I could get the
unhandledattributes from the element definition while reading the elements
with validatingreader. However, there is no such method. The only info which
I can glean during reading is SchemaType, which returns the definition of the
simple or complex type (including any unhadledattributes on the type
definition). however, the type for <A> is the same wherever it is used, so
that is of no help either.
4. I suppose I could read the SOM in parallel with the xml, but that really
amounts to replicating the work which the parser does!

Does anybody out there have a suggestion?
Thanks in advance.
Lisa

[Zafar Abbas]

If you use .net framework 2.0 beta2, there is a new validating reader
available in System.Xml which can be created using the static
XmlReader.Create methods. That reader provides a SchemaInfo Property which
contains, among other properties, a SchemaElement property which points to
the SOM element declaration, from where you can fetch the unhandled
attributes or any other data that you might need.
"Lisa" <Li**@discussions.microsoft.com> wrote in message
news:8D**********************************@microsof t.com...

I have to work with an existing xml where there is a root element and all
other elements are children of the root (in other words there is no nesting or hierarchy), e.g.
<myroot>
<A>adata</A>
<B>bdata</B>
<C>cdata</C>
<A>otheradata</A>
</myroot>

Unfortunately there are a lot of rules for the elements, such as choices
(e.g. A or B), groups which are mandatory or optional or repetitive, etc. and the elements can be used in various different groups. It is possible to write a schema which validates this accurately, so creating such xml and validating it is fine.
However, when receiving such data from somebody else, I would greatly
appreciate if the parser could actually let me know that it has e.g. found
<A> in the first (maybe optional) group. I have looked at various strategies: 1. use a default attribute which gives extra information. doesn't work,
because when compiling the schema, elements of same hierarchy level and same name may not have different default attributes.
2. use an id. Seems to be the same problem: id is an attribute. also I
haven't really found out how to work with ids.
3. use unhandledattributes. this would be a great method, if I could get the unhandledattributes from the element definition while reading the elements
with validatingreader. However, there is no such method. The only info which I can glean during reading is SchemaType, which returns the definition of the simple or complex type (including any unhadledattributes on the type
definition). however, the type for <A> is the same wherever it is used, so
that is of no help either.
4. I suppose I could read the SOM in parallel with the xml, but that really amounts to replicating the work which the parser does!

Does anybody out there have a suggestion?
Thanks in advance.
Lisa

[Lisa]

Dear Zafar,
thanks for the info - that is great news!
Regards,
Lisa

"Zafar Abbas" wrote:

If you use .net framework 2.0 beta2, there is a new validating reader
available in System.Xml which can be created using the static
XmlReader.Create methods. That reader provides a SchemaInfo Property which
contains, among other properties, a SchemaElement property which points to
the SOM element declaration, from where you can fetch the unhandled
attributes or any other data that you might need.
"Lisa" <Li**@discussions.microsoft.com> wrote in message
news:8D**********************************@microsof t.com...

I have to work with an existing xml where there is a root element and all
other elements are children of the root (in other words there is no

nesting

or hierarchy), e.g.
<myroot>
<A>adata</A>
<B>bdata</B>
<C>cdata</C>
<A>otheradata</A>
</myroot>

Unfortunately there are a lot of rules for the elements, such as choices
(e.g. A or B), groups which are mandatory or optional or repetitive, etc.

and

the elements can be used in various different groups. It is possible to

write

a schema which validates this accurately, so creating such xml and

validating

it is fine.
However, when receiving such data from somebody else, I would greatly
appreciate if the parser could actually let me know that it has e.g. found
<A> in the first (maybe optional) group. I have looked at various

strategies:

1. use a default attribute which gives extra information. doesn't work,
because when compiling the schema, elements of same hierarchy level and

same

name may not have different default attributes.
2. use an id. Seems to be the same problem: id is an attribute. also I
haven't really found out how to work with ids.
3. use unhandledattributes. this would be a great method, if I could get

the

unhandledattributes from the element definition while reading the elements
with validatingreader. However, there is no such method. The only info

which

I can glean during reading is SchemaType, which returns the definition of

the

simple or complex type (including any unhadledattributes on the type
definition). however, the type for <A> is the same wherever it is used, so
that is of no help either.
4. I suppose I could read the SOM in parallel with the xml, but that

really

amounts to replicating the work which the parser does!

Does anybody out there have a suggestion?
Thanks in advance.
Lisa