perfsonar development work

[Jason Zurawski <>]

Ulisses;

> > The example below probably fails most rules specified by NMWG :) I guess 
> > this is the reason why it won't create a DOM object
> >
> > - What is the purpose of the metadata element? It has no contents!
> > - Why do you have a data element inside another data element?
> > - Why do you have link element containing link meta information inside 
> > the data element? This clearly belongs under the metadata element (as it 
> > it meta information)
> >     
>
> yes, I found these problems and corrected already, the following minimal 
> version of xml also causes the same problem:
>
> <nmwg:message id="localhost.localdomain.66dffd41:10d3ab5e77b:-7ffe"
>     type="TOPSDownloadDBResponse" 
> xmlns:nmwg="http://ggf.org/ns/nmwg/base/2.0/";>
>     <nmwg:metadata id="TOPSDownloadDBResponseMetadata"/>
>     <nmwg:data id="TOPSDownloadDBResponse" 
> metadataIdRef="TOPSDownloadDBResponseMetadata">
>         <nmwg:data id="localhost.localdomain.66dffd41:10d3ab5e77b:-7fff">
>             <nmwgtopo3:link
>                 id="localhost.localdomain.66dffd41:10d3ab5e77b:-8000" 
> xmlns:nmwgtopo3="http://ggf.org/ns/nmwg/topology/l3/3.0/";>
>                 <nmwgtopo3:name>test</nmwgtopo3:name>
>             </nmwgtopo3:link>
>         </nmwg:data>
>     </nmwg:data>
> </nmwg:message>
>   

You haven't really addressed all of Loukik's original points:

1) The metadata is empty, but this should not cause DOM conversion problems.
2) You still have 2 data elements (one inside of the other) but this 
also will not cause conversion problems.
3) The link really should (in the spirit of our original design) be a 
metadata designated element, although the way the GGF classes are 
designed to 'bend' around unrecognized children elements the link will 
not cause a conversion problem. 

As I said in the previous e-mail I see no errors when doing a simple 
conversion using the Handler class and the toDOM() routine, but I am 
curious to see what method you are using that invokes these problems.



> > * Have you defined all possible message sequences for your service?
> >     
>
> it is an stateless service for now, do you refer to this?
>
>   


By message sequences Loukik means what the purpose of the request and 
the response are, and what they general format should be.  I don't 
believe you have ever roughed out an 'expected' sequence of exchanges to 
this service (i.e. a request document format and the resulting response 
document format).  Even though you have already started the physical 
service, it would be nice for me to see what your request and responses 
would look like.  That way we could decided how many data elements you 
would need, and if your metadata blocks need to be blank or not. 


> > * Are these message sequences agreed upon by NMWG (i.e Martin and Jason)
> >     
>
> maybe you are refering to the xml format/schema used?
>
> The following is a document with a more complete xml, including references 
> within the document,
> even Jason told me I should use org.ggf.ns.nmwg.topology.l3.v3_0.Interface, 
> currently I'm using
> org.ggf.ns.nmwg.topology.base.v3_0.Interface which seems to does the trick.
>
>   

Yes, you are using the topology elements from that particular schema, 
but the actual exchanges that this service will have between client 
applications or other services is very important as well.  Take a look 
at the (many) examples of exchanges that exist for the LS, or the 
various MAs.  Each request example is followed by an appropriate 
response instance document. 


>   
> > * If the above two points are done, are you sure your service is 
> > producing xml messages which are conforming to the agreements you might 
> > have had with NMWG?
> >     
>
> I think I don't understand what you mean with message sequences, do you refer 
> to xml schema?
>
>   

Message sequence would be TOPOQueryRequest -->  TOPOQueryResponse or 
something similar.  Once the actual messages are rouged out, then a 
specific schema (beyond the general topology elements) could be created 
just for your service. 

> > Finally, if all above are ok, what is the error message being produced 
> > (look at catalina.out if you are testing it on a deployed service)
> >     
>
> I think that I already asked you previously if it was possible force the 
> XML to DOM parser to tell in which line it is the error?
>
> The output is just:
>
> <?xml version="1.0" encoding="UTF-8"?>
> <nmwg:message xmlns:nmwg="http://ggf.org/ns/nmwg/base/2.0/"; 
> id="resultCodeMessage">
>    <nmwg:metadata id="resultCodeMetadata">
>       <nmwg:eventType>error.common.parse_error</nmwg:eventType>
>    </nmwg:metadata>
>    <nmwg:data id="resultDescriptionData_for_resultCodeMetadata" 
> metadataIdRef="resultCodeMetadata">
>       <nmwg:datum value="Cannot convert Message to DOM" />
>    </nmwg:data>
> </nmwg:message>
>
> I don't see any XML/DOM errors in the tomcat logs
>   

I see that you already filled a bug on the issue of 'line numbers' for 
the output errors.  I will see what I can do on that front, but perhaps 
someone that knows a bit better could clue us in as to which service 
component would generate the 'error.common.parse_error' to begin with?  
It does not get thrown in the base GGF classes, so I am guessing it is 
related to either a utility call or something in the axis libs? 

-jason