Hi (sorry for the long email) On Tue, 27 Nov 2012, John MacAuley wrote:
I understand the comments on the query. i was conflicted as well. I am also wondering if I meant AND :-)
I think this is ultimately a question on how people relate to risk. The argument for the current is that we will not have to change it later. OTOH there is the risk that we will have to maintain something complex over a long time, and that we will have to changes down the line no matter what (this is more how I see things). Right now, I see the biggest risk for NSI that we are not delivering and keep changing & adding things. If we have more demos we might start boring people to death. We will never figure out how this thing should look like until we had in production for some years. But this is how I see things and relate to risks, which is certainly different from the way other people see it.
The original Discovery response was the ServicesType structure, but based on the Chicago OGF/GLIF feedback I wrapped it with the NsaDiscoveryType to remove the need for the header. Other than this minor change it is the exact same as discussed in the last three or four OGF.
Aye, I just never had a look at it.
Now with this said, let us focus on the "9 levels deep" comment. This is probably the result of my specific XSD style. I like to wrap any multi-valued elements in a list type for containment. For example, the ServicesType wrapping the ServiceType, and the VersionsType wrapping the VersionType. Removing this containment can reduce the nesting by a few levels without any loss of data structure. However, this is the pattern I followed in the NSI-CS so I also followed it here.
I'm okay with that pattern. One thing I stumbled over was the heavy usage of attributes, but I could never figure out when to use elements and attributes in XML anyway. Now, things that stand out to me: The requestType and filtering seems completely overkill. Most services will only host 2 (CS and topology), perhaps 3 or 4 services. Maintaining multiple protocols stacks is tricky and will probably only be done for transitioning. This way of designing interfaces to be pretty popular 10 years ago, but these days things are typically modelled with complete, or most recent lists. I.e. less generic and more tailored to actual usage (I can dig up some articles on this if someone are interested). Given the low number of services modelling versions explicit seems overkill. Sure, there might be multiple ConnectionServices, but I can live with having NSI1SOAP and NSI2SOAP services types (or whatever we'll call them). The way capabilities are modelled also seems like overkill to me. They are binary, i.e., either they are there are not. Having looked at your slides I realize that you actually model it like that, but in slightly more complex way than I would. I'd probably do something like: <capabilities> <capability>release</capability> <capability>modify</capability> <capability> We might have QNames here. Or require it for 3rd party extensions. Not overly important. I honestly don't know if we need the capability stuff, but I am okay with it being there. It does seem broken to me though, as it typically won't be either or for these things. How do I represent that I can only do time extensions in modify, but not change the bandwidth. Or how do I specify that I can only increase link capacity, and not decrease it. Or that I cannot modify it beyond a limit? Or that I can only do modify on some ports, and not others. The capabilities stuff just strikes me as a bit naive, as the only way you can figure out of something can be done, is to fire off the action and see what happens. Similarly the ##other attributes strikes me as wrong, but I can for all purposes just ignore them for now. But if we keep the ##other attributes, we might as well make the base thing simple. I know that currently we support multiple providers at a single endpoint. This causes us to have nsaId in discovery and providerNSA in the CS header. While these things are relatively minor, I wondering if supporting this was a deliberate decision or it just ended up like that. It isn't like URLs are expensive, and it does cause a wee bit of extra complexity to support this. Btw. URL and endpoint - what is the difference? Is this just soap / non-soap services?
If you are partial to flatness, I could change everything to OWL and model though assertions and relationships. I certainly LOVE that model ;-)
I'd be okay if someone took OWL out back and shot it :-). (and I would not cry if they took N3 with them). So, in all I could see something like this for the discovery service: queryNsaRequest :: QueryNsaRequestType queryNsaResponse :: QueryNsaResponseType discovery :: NsaDiscoveryType * # softwareVersion # startTime # currentTime services :: ServicesType * service :: ServiceType # type :: xsd:string # url # wsdl # other :: any other :: any * capabilities :: CapabilitiesType * capability :: xsd:string It is a suggestion, but we don't really lose any functionality AFACIT. Best regards, Henrik Henrik Thostrup Jensen <htj at nordu.net> Software Developer, NORDUnet