XmlWriter - can't figure out how to create this element

[sklett]

**Disclaimer** The element I need to create might not be valid XML, but
it's not my fault, I'm following a required format for an integration
project.

I've got 99% of the XML created nicely using XmlWriter, there is one line
that I can't figure out how to generate:
<ServicesCertifiedMail="OFF" DeliveryConfirmation="ON" ></Services>

I've tried several different combinations of methods and can't seem to
generate that string. Is it possible? If so, anyone know what I need to
do? I tried calling WriteString but it replaced the "<>" characters with
something else.

Thanks for reading,
Steve

 

[Marc Gravell]

Have you tried WriteRaw()?

Marc

 

[Jon Skeet [C# MVP]]

**Disclaimer** The element I need to create might not be valid XML, but
it's not my fault, I'm following a required format for an integration
project.

Well, it's definitely not XML, and won't be able to be parsed by any
XML parser.

If you need to write non-XML, I suggest you use something other than an
XmlWriter - while stressing to management (or whoever) that it's a
pretty horrible file format.

One alternative would be to write "real" XML and then a second process
which took the real XML and generated the required pseudo-XML. That way
you could still use real XML for most of the processing, which may well
make things easier.

 

[sklett]

Hi Narc,

I somehow missed WriteRaw() last night, thanks for the suggestion! I just
tried it and it does write out the exact string I've given it, but with a
strange side effect: All subsequent calls to WriteElementString are being
placed on the same line, one after another.
Here is an example:
<PackageType>RECTPARCEL</PackageType>
<WeightOz>1.7</WeightOz>
<Width>10</Width>
<Length>10</Length>
<Depth>10</Depth>
<ServicesCertifiedMail="OFF" DeliveryConfirmation="ON" ></Services>
<Value>0.00</Value><Description>Sales Order#
531</Description><ReferenceID>531</ReferenceID>


After the lined starting with "<Services..." everything is getting throw on
the same line. I tried resetting the formating but that didn't make any
difference. Here is the code that seems to be causing the problem:
<code>
writer.WriteElementString("PackageType", "RECTPARCEL");
writer.WriteElementString("WeightOz", package.Weight.ToString());
writer.WriteElementString("Width", "10");
writer.WriteElementString("Length", "10");
writer.WriteElementString("Depth", "10");

// <ServicesCertifiedMail="OFF" DeliveryConfirmation="ON" ></Services>
// This is a non-standard element (I think) so I'm just dumping the string
literal into the file
writer.WriteRaw(Environment.NewLine);
writer.WriteRaw("<ServicesCertifiedMail=\"OFF\" DeliveryConfirmation=\"ON\"

</Services>");

writer.WriteRaw(Environment.NewLine);
writer.Formatting = Formatting.Indented;

writer.WriteElementString("Value", "0.00");
writer.WriteElementString("Description", package.ReferenceLine1);
writer.WriteElementString("ReferenceID",
fulfillment.SalesOrder.TransactionNumber);
</code>

Do you see anything there that would cause the writer to not write line
breaks after the call to WriteRaw()?

Thanks for any ideas,
Steve

 

[sklett]

Thanks for the ideas and suggestions Jon.
I have been making noise to the api developers for this specific tool....
they just don't care.
I'm real close to having a working solution, just need to sort out a newline
issue (posted in previous message).

Thanks again for the suggestions,
Steve

 

[clintonG]

From what I've observed, your XML is poorly formed and lacks consistent
structural style. You are using both elements and attributes which I concede
may be neccessary but in general just as often can and probably should be
restructured.

Secondly, the following use of an attribute as an element name is the
poorest type of form I have ever observed:

<ServicesCertifiedMail="OFF" DeliveryConfirmation="ON" ></Services>

To solve the problem you are talking about -- in this news article -- simply
refine your form:

<CertifiedMailServices serviceState="off" deliveryConfirmation="on" />

Some time ago I wrote a similar RFI regarding style, form, and in particular
naming conventions was answered by Oleg Tkachenko an XML MVP [1]. I found
his reply useless as it obviates common sense.

The format I wrote above is what I have adopted ehich follows Tkachenko's
sage comments; the format being consistent with my use of C#. Further, what
I suggest one learn from this form of styling is the fact that the XmlWriter
will write attributes easily and as expected when the base form is in fact
well-formed and consistent of the ideal of that state of being well-formed,
i.e. when we clean up our sloppy form many of our problems go away. So I'm
trying to tell ya'...

Get some style boy ;-)

<%= Clinton Gallagher
NET csgallagher AT metromilwaukee.com
URL http://clintongallagher.metromilwaukee.com/

[1] http://www.thescripts.com/forum/thread178080.html

 

[sklett]

Thank you for the reply, however I wish you had read the original post.

"**Disclaimer** The element I need to create might not be valid XML, but
it's not my fault, I'm following a required format for an integration
project."

This is not my format, I know it's ugly and I don't like having to use it
anymore that you would.
But I can't change the fact that the host application I'm integrating with
will be parsing this file and it cannot be changed.

Thanks again for the reply,
Steve

From what I've observed, your XML is poorly formed and lacks consistent
structural style. You are using both elements and attributes which I
concede may be neccessary but in general just as often can and probably
should be restructured.

Secondly, the following use of an attribute as an element name is the
poorest type of form I have ever observed:

<ServicesCertifiedMail="OFF" DeliveryConfirmation="ON" ></Services>

To solve the problem you are talking about -- in this news article --
simply refine your form:

<CertifiedMailServices serviceState="off" deliveryConfirmation="on" />

Some time ago I wrote a similar RFI regarding style, form, and in
particular naming conventions was answered by Oleg Tkachenko an XML MVP
[1]. I found his reply useless as it obviates common sense.

The format I wrote above is what I have adopted ehich follows Tkachenko's
sage comments; the format being consistent with my use of C#. Further,
what I suggest one learn from this form of styling is the fact that the
XmlWriter will write attributes easily and as expected when the base form
is in fact well-formed and consistent of the ideal of that state of being
well-formed, i.e. when we clean up our sloppy form many of our problems go
away. So I'm trying to tell ya'...

Get some style boy ;-)

<%= Clinton Gallagher
NET csgallagher AT metromilwaukee.com
URL http://clintongallagher.metromilwaukee.com/

[1] http://www.thescripts.com/forum/thread178080.html

**Disclaimer** The element I need to create might not be valid XML, but
it's not my fault, I'm following a required format for an integration
project.

I've got 99% of the XML created nicely using XmlWriter, there is one line
that I can't figure out how to generate:
<ServicesCertifiedMail="OFF" DeliveryConfirmation="ON" ></Services>

I've tried several different combinations of methods and can't seem to
generate that string. Is it possible? If so, anyone know what I need to
do? I tried calling WriteString but it replaced the "<>" characters with
something else.

Thanks for reading,
Steve

 

[Jon Skeet [C# MVP]]

I somehow missed WriteRaw() last night, thanks for the suggestion! I just
tried it and it does write out the exact string I've given it, but with a
strange side effect: All subsequent calls to WriteElementString are being
placed on the same line, one after another.

Do you see anything there that would cause the writer to not write line
breaks after the call to WriteRaw()?

I expect it may be getting confused by trying to parse the contents of
your WriteRaw call to work out what's going on - I'm not sure, to be
honest.

*If* this is the case, an alternative (horrible though it is) would be
to flush the XmlWriter and manually write to the output stream before
continuing to use the XmlWriter.

 

[Jon Skeet [C# MVP]]

Thanks for the ideas and suggestions Jon.
I have been making noise to the api developers for this specific tool....
they just don't care.

Is this an internal API? If so, raise the issue with managers - it's
dangerous to let this kind of thing go unreported.

If it's an API from another company, I'd look for alternatives - if a
company doesn't care about following standards as widely used as XML,
who knows what other things they don't care about, such as reliability,
responsiveness to bug reports etc.

 

[sklett]

Is this an internal API? If so, raise the issue with managers - it's
dangerous to let this kind of thing go unreported.

No, not internal, if it was I would fix ths crap myself

If it's an API from another company, I'd look for alternatives - if a
company doesn't care about following standards as widely used as XML,
who knows what other things they don't care about, such as reliability,
responsiveness to bug reports etc.

The vendor I'm integrating with was not a first choice. I had originally
invested quite a bit of time directly with USPS's integration tools but
overlooked the apparent fact that you can't *actually* purchase postage from
USPS, you can verify addresses, requrest a label, etc. but there isn't a way
to get POSTAGE on the label from them. This blew me away, I coldn't
understand why, especially considering you CAN purchase postage on the web
site. Strange.

I'm integrating with a tool called "DAZzle" from Endicia. It's not perfect,
but does allow me to get something in place why we consider other options.
We don't have the budget to integrate with the larger, more robust solutions
that are out there.

Maybe you will appreciate this: :0)
1) agregate my transaction details from our CRM/ERP solution (which is VERY
powerful and open (NetSuite))
2) generate an xml file with the postage settings
3) launch a DAZzle process passing said xml file path on the command line
4) parse the result "output XML" file that DAZzle creates and store the
relevant data (tracking numbers, error codes, etc)

I have no control over the printer, the DAZzle process does that. Printer
out of paper or Printer offline? - I have now way to detect that.
It's not pretty, but like I said, it's what we can afford at this time.

If anyone knows of other options to create USPS postage labels WITH postage
I would LOVE to hear about it.

BTW, I don't mean to trash DAZzle, it's a fine little application but
integration was not it's intention and I suspect has been slipped in along
the way.

Thanks,
Steve

 

[RedGrittyBrick]

**Disclaimer** The element I need to create might not be valid XML, but
it's not my fault, I'm following a required format for an integration
project.

I wouldn't attempt to use XML tools to write something that isn't XML.

<ServicesCertifiedMail="OFF" DeliveryConfirmation="ON" ></Services>

That looks like a simple typing error where a space has been omitted.
<Services CertifiedMail="OFF" DeliveryConfirmation="ON" ></Services>
would be well-formed XML.

 

[sklett]

I wouldn't attempt to use XML tools to write something that isn't XML.



That looks like a simple typing error where a space has been omitted.
<Services CertifiedMail="OFF" DeliveryConfirmation="ON" ></Services>
would be well-formed XML.

Sure does! I'm looking for other documentation on their site to see if this
is the case. The examples in the implementation guide have it without the
space, but you make a very interesting observation.

Thanks! - I bet it's a typo.

 

[Jon Skeet [C# MVP]]

BTW, I don't mean to trash DAZzle, it's a fine little application but
integration was not it's intention and I suspect has been slipped in along
the way.

Again, that doesn't sound like a promising situation.

You should at least raise it as a concern somewhere - a non-responsive
vendor using non-standard formats should raise a red flag. If there's
no alternative, then fair enough - but it's worth escalating so that if
things go wrong, you can at least say you've warned them