Tim,
Thanks for
your follow up. I had a chat
with Jon yesterday about this topic and he suggested it was an Altova
problem.
Should someone be advising them of this problem? Do we know who to tell
what?
All I wanted to do was get some kind of working example that I could
start
replicating to create a scenario of statuses that track the shipment
along the supply
chain.
My next
challenge is to understand how to
portray the output for human readability. All suggestions welcome……
Andy
Well i am glad you made me
revisit this. It
reminded me of problems we had with XMLSpy for UBL 1.0 as well.
The issues is that UBL has several recursive structures (a GoodsItem
may
contain other GoodsItem, a Package other Packages, etc...). If you
think
about this tools like XMLSpy don't know when to stop going down this
branch. It doesn't have an option to say "only go to 2nd depth of
recursion".
What happens with XMLSpy is it kind of goes a bit crazy and gives up
but
doesn't tell you that. It just creates an invalid instance. my
feeling is these errors are almost randomly different each time. I can
understand your frustration!
The specific problem with the TransportationStatus document is that its
TransportEvent contains ReportedShipment. ReportedShipment contains
GoodsItem (and that can contain other GoodsItems). ReportedShipment is
the problem child.
There is a workaround for XMLSpy.
It transpires that XMLSpy can deal with these recursive structures if
they are
the last child of its parent. Think of this as the rightmost box on
the
UML diagrams or the last ASBIE for the ABIE in the spreadsheets.
So if TransportEvent contained CurrentStatus, Contact and
ReportedShipment then
XMLSpy could create a valid instance for you. However TransportEvent
actually says ReportedShipment, CurrentStatus and Contact, so it
doesn't.
Crazy but true.
My way of fixing this was to edit the schema to make the order of
associations
within TransportEvent to be CurrentStatus, Contact and ReportedShipment
and
create an instance from this. Then i edited the instance to move
ReportedShipment to above CurrentStatus. It then validates correctly
against the correct PRD2 schema. The result is attached. (you will
need
to change the name to a .zip and unzip it)
In a sense this is not a problem for UBL as schemas behaved correctly.
But it does make me think other applications may face similar
problems.
Perhaps in our designing of ASBIEs we could be sensitive to some
technology
issues like this and consider placing recursive structures at the end
of their
containing structure?
NB I will copy this to the UBL list in case others have similar
problems or
better solutions.
PS dont forget to use the Enhanced Grid view when edit this with XMLSpy
- it
makes life a lot easier. And if you open the Forwarding Instructions
instance at the same time you should be able to cut and paste sections
from one
to the other.
Andrew Schoka wrote:
I was working with Paul Thorpe who used a tool based on the ASN.1 version
and he produced the attached. I guess it’s a start.....
Andy
Original Message-----
From: [mailto:tmcgrath@portcomm.com.au]
Sent: Wednesday, August 16, 2006 7:36 PM
To: Andrew Schoka
Subject: Re: [ubl-tsc] Order and Forwarding Instructions document instances.
let me try it from my end and send you an abbreviated template.
i did get some wierd results at one stage but cannot recall how i got
around it.
Andrew Schoka wrote:
Tim,
I have to say that my experience with XMLSpy have been less than favorable
while trying to create an instance of the Transportation Status Message. I
have spent the better part of the F2F meeting days trying to get it to
work.
While I readily admit I am quite a rookie at XML and XML tools, I think
that
the Transport Status instance cannot be fully instantiated; ie I think Spy
runs out of buffer space while trying to get to the end of the instance. I
can't seem to get to the point where I can get an instantiation of the
current status or beyond........
Maybe I am doing something basically wrong, but I just can't figure it
out...... grrrrrrrr
Andy
Original Message-----
From: [mailto:tmcgrath@portcomm.com.au]
Sent: Thursday, August 10, 2006 11:08 PM
To: ubl-tsc@lists.oasis-open.org
Cc: ubl-psc@lists.oasis-open.org
Subject: [ubl-tsc] Order and Forwarding Instructions document instances.
I have made minor modifications to the previous sample Order document
and created a Forwarding Instructions instance based on this.
Can you each review this document and see if it makes sense. Once we
get agreement on this we can turn it into a Waybill then Transportation
Status and CoO document. It is quite small so just opening it with a
browser or text editor should give you the overall idea.
PS I have found XMLSpy quite good for this exercise, it allows cutting,
pasting and renaming of elements within and between documents and it is
relatively easy to edit values (especially if you stick to the Enhanced
Grid view). However you must install these istances in the PRD2
directory called /xml for validation against schemas to work.
<?xml version="1.0" encoding="UTF-8"?>
<ns38:TransportationStatus xmlns:ns5="urn:oasis:names:specification:ubl:schema:xsd:CommonBasicComponents-2" xmlns:ns38="urn:oasis:names:specification:ubl:schema:xsd:TransportationStatus-2" xmlns:ns4="urn:oasis:names:specification:ubl:schema:xsd:CommonAggregateComponents-2">
<ns5:ID>0</ns5:ID>
<ns5:Description>0</ns5:Description>
<ns5:Note>0</ns5:Note>
<ns4:Consignment>
<ns5:ID schemeAgencyID="0" schemeAgencyName="0" schemeDataURI="0" schemeID="0" schemeName="0" schemeURI="0" schemeVersionID="0">0</ns5:ID>
<ns5:SummaryDescription>0</ns5:SummaryDescription>
</ns4:Consignment>
<ns4:TransportEvent>
<ns5:IdentificationID>0</ns5:IdentificationID>
<ns5:OccurrenceDate>+</ns5:OccurrenceDate>
<ns5:OccurrenceTime>+</ns5:OccurrenceTime>
<ns5:TransportEventTypeCode>0</ns5:TransportEventTypeCode>
<ns5:Description>0</ns5:Description>
<ns5:CompletionIndicator>true</ns5:CompletionIndicator>
<ns4:ReportedShipment>
<ns5:ID>0</ns5:ID>
<ns4:Consignment>
<ns5:ID>0</ns5:ID>
</ns4:Consignment>
</ns4:ReportedShipment>
<ns4:CurrentStatus>
<ns5:ConditionCode>0</ns5:ConditionCode>
<ns5:ReferenceDate>+</ns5:ReferenceDate>
<ns5:ReferenceTime>+</ns5:ReferenceTime>
<ns5:Description>0</ns5:Description>
<ns5:StatusReasonCode>0</ns5:StatusReasonCode>
<ns5:StatusReason>0</ns5:StatusReason>
<ns5:SequenceID>0</ns5:SequenceID>
<ns5:Text>0</ns5:Text>
<ns5:IndicationIndicator>true</ns5:IndicationIndicator>
<ns5:PercentNumeric>0</ns5:PercentNumeric>
</ns4:CurrentStatus>
<ns4:Contact/>
</ns4:TransportEvent>
<ns4:DocumentReference>
<ns5:ID>0</ns5:ID>
</ns4:DocumentReference>
<ns4:Signature>
<ns5:ID>0</ns5:ID>
<ns4:SignatoryParty/>
</ns4:Signature>
</ns38:TransportationStatus>
--
regards
tim mcgrath
phone: +618 93352228
postal: fremantle 6160
web: http://www.portcomm.com.au/tmcgrath