I want to promote an unqualified attribute that is part of an envelope
schema. But it seems that only qualified attributes can be promoted this way
.
Is that correct?

e.g. Using the envelope below, the myEnvVersion attribute will not be promot
ed

<ns0:myEnv xmlns:ns0='''...">
<ns0:myEnvElem myEnvVersion="1.0"/>
<ns0:Body>
...
</ns0:Body>
</ns0:myEnv>

But if the attribute is qualified, e.g. ns:myEnvVersion="1.0", The attribute
will be promoted.

[ Post a follow-up to this message ]

Hi,

How does your envelope schema look like? Especially, what have you defined
"AttributeFormDefault" to be? With that setting, you can define how
attributes should be managed concerning their namespace prefix.

Sincerely

Joerg Fischer

"Frans van der Geer" <FransvanderGeer@discussions.microsoft.com> wrote in
message news:0696BD67-8B27-4A38-B53C-B66911CD3C7F@microsoft.com...
> I want to promote an unqualified attribute that is part of an envelope
> schema. But it seems that only qualified attributes can be promoted this
way.
> Is that correct?
>
> e.g. Using the envelope below, the myEnvVersion attribute will not be
promoted
>
> <ns0:myEnv xmlns:ns0='''...">
>    <ns0:myEnvElem myEnvVersion="1.0"/>
>    <ns0:Body>
> ...
>    </ns0:Body>
> </ns0:myEnv>
>
> But if the attribute is qualified, e.g. ns:myEnvVersion="1.0", The
attribute
> will be promoted.

[ Post a follow-up to this message ]

The envelope schema has AttributeForm default, which is unqualified.
The field I want to be promoted is imported from another schema, which also
has AttributeForm default, i.e. unqualified.

But that's my point: when the incoming XML document includes the unqualified
attribute, the field does not get promoted. When instead the XML document
includes the attribute in a qualified form, the field does get promoted. But
then the XML document does not conform to my schema, because it does not
allow qualified attributes.

Frans.

"Joerg Fischer >" wrote:

> Hi,
>
> How does your envelope schema look like? Especially, what have you defined
> "AttributeFormDefault" to be? With that setting, you can define how
> attributes should be managed concerning their namespace prefix.
>
> Sincerely
>
> Joerg Fischer
>
> "Frans van der Geer" <FransvanderGeer@discussions.microsoft.com> wrote in
> message news:0696BD67-8B27-4A38-B53C-B66911CD3C7F@microsoft.com... 
> way. 
> promoted 
> attribute 
>
>
>

[ Post a follow-up to this message ]

Hi,

When you promote a field from a schema, the XPAth of the field gets written
into the schema. Check that these XPathes are correct.

If they are, then I assume we are facing a problem in how the XPathes are
handled by BizTalk / .NET here.

Have you control over the schemas so that you can alter them in case?

Sincerely

Joerg Fischer

"Frans van der Geer" <FransvanderGeer@discussions.microsoft.com> wrote in
message news:F26CA1CD-93BC-4AEF-BE08-E0ABA9AB157D@microsoft.com...
> The envelope schema has AttributeForm default, which is unqualified.
> The field I want to be promoted is imported from another schema, which
also
> has AttributeForm default, i.e. unqualified.
>
> But that's my point: when the incoming XML document includes the
unqualified
> attribute, the field does not get promoted. When instead the XML document
> includes the attribute in a qualified form, the field does get promoted.
But[vbcol=seagreen]
> then the XML document does not conform to my schema, because it does not
> allow qualified attributes.
>
> Frans.
>
> "Joerg Fischer >" wrote:
> 
defined[vbcol=seagreen] 
in[vbcol=seagreen] 
this[vbcol=seagreen] 

[ Post a follow-up to this message ]

Hi Joerg,

You put me on the right track. The problem is that an unqualified attribute
does not belong to any namespace per definition. But when you promote an
attribute in the Biztalk Editor, it generates an XPath expression including 
a
namespace-uri condition. So I simply edited the xpath expression by hand,
i.e. removed the namespace-uri condition and now my envelope behaves as
desired.

Thanks,

Frans

"Joerg Fischer >" wrote:

> Hi,
>
> When you promote a field from a schema, the XPAth of the field gets writte
n
> into the schema. Check that these XPathes are correct.
>
> If they are, then I assume we are facing a problem in how the XPathes are
> handled by BizTalk / .NET here.
>
> Have you control over the schemas so that you can alter them in case?
>
> Sincerely
>
> Joerg Fischer
>
> "Frans van der Geer" <FransvanderGeer@discussions.microsoft.com> wrote in
> message news:F26CA1CD-93BC-4AEF-BE08-E0ABA9AB157D@microsoft.com... 
> also 
> unqualified 
> But 
> defined 
> in 
> this 
>
>
>

[ Post a follow-up to this message ]