XML ports are sequentiel?

trinsan

I'm having some difficulties understanding 2009's ability to handle XML.

As far as I understand, the import or export of data through defined XML ports is fixed / sequentiel ignoring the dynamics of tag use in XML.

E.g. I receive files from multiple sources

Source 1
<customer>
<customername>Brett Nelson</customername>
<customeraddress>125 Hyphen</customeraddress>
<customeremail>bm@hyphen.org<customeremail>
</customer>

Source 2
<customer>
<customername>Brett Nelson</customername>
<customeremail>bm@hyphen.org<customeremail>
<customeraddress>125 Hyphen</customeraddress>
</customer>

So, if I am to import such files, I will need two dataports and not one, as Navision expects the tags to always appear in the same sequential order.

If such is the case, its downright ridiculous, as one of the main targets of XML is the use of tags as a referer and not its position in the file, in much the same way as you refer to a fieldname in a database and not the field name's position in the table.

Could anyone confirm / deny the above to be true?

Cheers, T

jhoek

I'm pretty sure this is true (and yes, it seems ridiculous).

As a work-around, you might consider using an XSLT-stylesheet that transforms your xml-files into the format that NAV expects, e.g. changing the order of elements?

ara3n

I don't think it's ridiculous.

The structure of an xml file is defined by an xsd file and I don't believe in one xsd you can define the two example you have provided.

They are two different xml structures.


You can always use MSDOM and dynamically parse your xml file. I wish you good luck with that.

rdebath

An xsd can define those two layouts in one definition; quite easily actually. It's just not the 'dumb default'.

Microsoft's XMLports are very very limited and only really of practical use where the XMLport defines the layout.
The processing of attributes is actually wrong, because it's order sensitive. The XML standards state explicitly that the order is "not significant". http://www.w3.org/TR/REC-xml/#sec-starttags

For anything that an XMLport can do the DOMDocument interface isn't any more difficult. Syntactically it's a bit cumbersome, so you'll want to wrap it in a codeunit. It does, however, seem rather poorly thought out for the more complex stuff, (That an XMLport can't do) though I think it's probably more a documentation problem myself.

Though, one advantage that an XMLPort has over the DOMDocument is that the DOMdocument loads the entire XML into memory. The XMLPort streams it in like a CSV file (yes they're "sequentiel"). Surprisingly this doesn't seem to give much of a speed advantage to the XMLPort, but it does mean it uses a lot less memory. But if you're loading bulk data WTF are you doing using XML! [-X

jhoek

Fully agree, Robert, but I'm not sure what you mean by

seem rather poorly thought out for the more complex stuff

Could you please elaborate on that a little? Thanks!

rdebath

Okay, some examples.

Change the character set: The underlying character set for XML is always full 32 bit unicode (or should be) but the character set for the file can be any of a long list. It's very reasonable to want to switch a document to a different character set (eg: to ASCII for a channel with broken, or fixed, character set conversions) and conceptually very simple. It's evil with MSXML.

Namespaces, just namespaces. MSXML uses one rather weird model for them where it tries to hide the existence of the prefix, sort of.

Whitespace processing. I think MSXML tries to please everyone here, it ends up more than a bit confusing.

I suspect the core problem is that XML is basically misused in the majority of applications. Supposedly, it's designed as a document markup language. This implies the existence of a plain text document to be marked up by the XML, not just a list of random numbers and strings. If you look at the APIs for things that are supposed to be used for storing values and building messages they are rather different. Things like INI file editors and database interfaces spring to mind.

This gets me back to the beginning; IMO, the main reason for using XML is that there's a nice fat specification that defines how XML should work in every situation. MSXML is pretty good at sticking to that specification, XMLPorts are really bad at this. Thus XMLPorts are good for nothing ...

Of course that's an overstatement (but only slightly), however, it is likely to mean that XMLPorts are only useful if you control both ends of a connection.

ara3n

I disagree with the "statement xmlports are good for nothing".

They are good for making parsing XML files SIMPLE. And that is the goal of it. Otherwise they wouldn't have created. XMLDOM is always there.

Why is it simple, no parsing of code. When you are dealing with integration where there are 10-20 integration points, using xmlports in conjunction with XMLDOM makes the integration simple an manageable.

rdebath

ara3n wrote:

I disagree with the "statement xmlports are good for nothing".

Of course you do, it's an aggressive blanket statement.

ara3n wrote:

They are good for making parsing XML files SIMPLE. And that is the goal of it. Otherwise they wouldn't have created. XMLDOM is always there.

Why is it simple, no parsing of code. When you are dealing with integration where there are 10-20 integration points, using xmlports in conjunction with XMLDOM makes the integration simple an manageable.

I'm not sure what you're trying to get at here, but they're not really that simple; you have write a chunk of code to get a filename (common dialog) open it and turn it into a stream; all of which you got for nothing with dataports. Then unless the XML is coming from another XMLport you'll probably have to put it through an XSLT transform so that it fits what the XMLPort can read which kinda defeats the object.

I've tried to use XMLports several times since they first arrived, just once were they able to do the job. For a simple export, not an import.