| Author |
Message
|
| llaros |
 Posted: Thu Jan 31, 2008 9:15 am Post subject: |
 |
|
Apprentice
Joined: 22 Jan 2008
Posts: 37
|
Jeff
I appreciate your help but I'm also confused that we don't understand each other. Please read my posts carefully or please be patient and write what should I do to make it work.
xsi:type is an attribute in xml which indicates type of the element, but it is a feature which is beyond the message logical model. (It is my opinion and I could be wrong but unlikely)
I don't need it (xsi:type) in TDS because I try to tell the broker about a type by specifying distinct delimiter for a subtype. Moreover xsi:type is not allowed in TDS (?)
If you think that I should define xsi:type element as an XMLAttribute in Vehicle type then write how to do it because it is not trivial contrary to unprefixed attribute. |
|
| Back to top |
|
 |
| jefflowrey |
| Posted: Thu Jan 31, 2008 9:21 am Post subject: |
|
|
Grand Poobah
Joined: 16 Oct 2002
Posts: 19981
|
Hrm. My fault. I lost track of where the conversation was going.
Enable validation on the MQInput node.
_________________
I am *not* the model of the modern major general. |
|
| Back to top |
|
|
| kimbert |
| Posted: Thu Jan 31, 2008 11:07 am Post subject: |
|
|
Jedi Council
Joined: 29 Jul 2003
Posts: 5543
Location: Southampton
|
You can safely ignore the BIP5605W - the TDS parser wasn't expecting users to do what you are doing.
As I said earlier in this thread, it is OK to have xsi:type attributes in the message tree even for non-XML formats. The logic which overrides the declared type with the xsi:type is in the 'logical layer' which is common to CWF, TDS and MRM XML.
I think we are exactly where we thought we were a couple of days ago, Either someone at Hursley needs to diagnose this, or you need an alternative solution. You can choose your option based on how soon you need an answer.. |
|
| Back to top |
|
|
| llaros |
| Posted: Fri Feb 01, 2008 3:25 am Post subject: |
|
|
Apprentice
Joined: 22 Jan 2008
Posts: 37
|
Within more or less two months we would like to have alternative format that produces significantly shorter messages and we consider
two reasonable options:
1) Try to make TDS which would (if it works) produce the best (shortest) output and can be easily implemented on the applications sides.
But there some unsolved WBI TDS parser "how-to"s WBI TDS parser (the one described in this thread, recursive types, and the rumors that is not that fast - due to the flexibility)
2) Make alternative XML physical format based on the same logical format but use very short tags - generate max 3 letter unique substitutes.
We have more than 500 data types and 100+ messages but all *.mxsd are generated automatically so it would be a problem - but the message will not be that short.
3) Write own parser - does not sound good since the custom parser cannot access the *.mxsd data (or we don't know how). The customer would be forced to install two components (mxsd and special data model file for a parser). We do not believe that is is gonna work in a practice.
4) Wait for a binary XML in WMB (V6.2 ?)  |
|
| Back to top |
|
|
| jefflowrey |
| Posted: Fri Feb 01, 2008 5:29 am Post subject: |
|
|
Grand Poobah
Joined: 16 Oct 2002
Posts: 19981
|
You can't do recursive types in TDS, either...
*******
EDIT: I might mean something slightly differently than "recursive types".
I mean you can't define a group A that contains an element of itself, or an element of Group B that contains an element of group A.
*******
You can approximate it, by using an "any" element and an open composition.
But it's not a true recursive type.
_________________
I am *not* the model of the modern major general.
Last edited by jefflowrey on Sat Feb 02, 2008 7:55 am; edited 1 time in total |
|
| Back to top |
|
|
| kimbert |
| Posted: Fri Feb 01, 2008 3:11 pm Post subject: |
|
|
Jedi Council
Joined: 29 Jul 2003
Posts: 5543
Location: Southampton
|
1) Can work
2) Really bad idea - sacrificing maintainability is almost never the right answer
3) Probably quite a lot harder than you think
4) We have no plans for this at all. There's not even a published standard to implement! |
|
| Back to top |
|
|
| shanson |
| Posted: Wed Feb 27, 2008 7:55 am Post subject: |
|
|
Partisan
Joined: 17 Oct 2003
Posts: 344
Location: IBM Hursley
|
I will wade in with several comments here:
a) Using TDS as a way of serialising XML in a compact manner is not a good idea. TDS will never implement all of XML Schema so there will come a point when you are stuck.
b) People using REST style Web Services often use JSON as a compact way of sending their data instead of XML. You'd need to look at the spec for JSON, it's flexible but I can't recall whether it allows dynamic type specification and/or recursion. A JSON parser in WMB will probably happen at some point.
c) DFDL is not designed to support binary XML. DFDL is for modelling non-XML data. As currently proposed, DFDL 1.0 will not support complex type inheritance.
d) You should raise an MQREQ for WMB to consider supporting W3C EXI, although the standard is still in draft so don't hold your breath.
e) Meantime I think you are forced to adopt one or more of the following:
1. Omit all XML comments and white space
2. Use short XML tags
3. Base64 encode the entire XML document, treat as BLOB in WMB and decode before parsing using one of the XML parsers
To achieve 2 consider the following approaches:
- Use schema annotations to document the real name to preserve schema maintainability
- Use MRM XML as the parser and make use of the 'XML Name' property of an element - this lets you change the tag name |
|
| Back to top |
|
|
| llaros |
| Posted: Thu Feb 28, 2008 1:37 am Post subject: |
|
|
Apprentice
Joined: 22 Jan 2008
Posts: 37
|
| Thanks for your post. Of course we will consider using Efficient XML Interchange what seems to be best not just for our solution. I hope that this will become a standard soon. |
|
| Back to top |
|
|
| JLRowe |
| Posted: Thu Feb 28, 2008 3:14 am Post subject: |
|
|
Yatiri
Joined: 25 May 2002
Posts: 664
Location: South East London
|
Depending on the nature of your problem: Is the message too big for the network (causing long transmission times) or too big for message broker (long parse/serialize times and/or out of memory errors), it may be worth investigating a java solution.
There is a binary XML parser available called fast infoset, see this URL for details:
http://java.sun.com/developer/technicalArticles/xml/fastinfoset/
This would make the message a lot smaller, with the flipside being a lot of processing in the broker. If your messages are flowing over WMQ then you can always turnon channel compression, that would be far simpler and would mean that your broker code can be just be written as normal without having to be concerned with message size. |
|
| Back to top |
|
|
|
|
