Hi Freek/All; On 8/16/11 8:32 AM, thus spake Freek Dijkstra:
Comments follow original text:
Roman Łapacz wrote:
So far, we have seen these two proposals:
<nml:link id="urn:ogf:network:example.net:link_A-to-C"> <nml:relation type="serialcompound"> ... </nmlserialcompound:relation> </nml:link>
and:
<nml:link id="urn:ogf:network:example.net:link_A-to-C"> <nmlserialcompound:relation> ... </nmlserialcompound:relation> </nml:link>
The advantage of the first syntax is that it is very easily extendable, and it is still obvious for a parser to understand that it is some kind of nml:relation, even if the particular type of relation is not known by the parser.
The advantage of the second syntax is that it is easy to create a meaningful validator for each specific nml:relation.
I dislike both syntaxes, and was hoping for a syntax that would provide both benefits.
If I'm correct, the following syntax will do just that:
<nml:link id="urn:ogf:network:example.net:link_A-to-C"> <nml:relations> <nmlserialcompound:relation> ... </nmlserialcompound:relation> </nml:relations> </nml:link>
This adds a parent element to the relation elements, signifying that <nmlserialcompound:relation> is indeed a nml:relation. So even a parser that has no knowledge about this particular nml:relation still knows it's base syntax, while a parser that understands the details can still use an meaningful syntax validator (such as XSD) to make sure the syntax is correct.
The solution with namespaces gives you that (nmlserialcompound:relation inherits from the base nml:relation). nml:relations only complicates the xml structure without giving too much.
You mean you prefer the following?:
<nml:link id="urn:ogf:network:example.net:link_A-to-C"> <nmlserialcompound:relation> ... </nmlserialcompound:relation> </nml:link>
I would prefer there to be just 'nml:relation' because it is still not clear to me what you intend to put in the 'nmlserialcompound' relationship that is special enough to be in a different namespace. Do you have examples of what you intend to do with this relationship? In any event, what I think doesn't matter in this case, because your sub-namespace (nmlserialcompound) would derive from the base namespace (nml). Which is the entire point of doing things in this manner. Even though its a special namespace, it can be reduced to the base which should make services happy.
How should the parser know that nmlserialcompound:relation inherits from the base nml:relation? I can think of two things:
- Because the parser has knowledge of the schema definition
Yes, its written in the schema implicitly. If the parser for some service was loaded with the 'nmlserialcompound' version of the schema, that schema has to have in it somewhere that 'nmlserialcompound:relation' is really just an 'nml:relation' that has been extended. This service is intelligent enough to parse both 'nml' and 'nmlserialcompound' versions. The converse is that a service that has no knowledge of the 'nmlserialcompound' relationship may not be able to read the elements. It would only be able to interpret the relations as 'nml' - if it is able to interpret them at all. Strict validation may force the 'nmlserialcompound' namespaced elements to be ignored or rejected (depends on the semantic rules).
- Because the parser assumes that all elements named "relation" are subclasses of nml:relation.
I dont think you can make this assumption. It is true that some non-strict checking services may take this path, but semantic rules can be enforced if so desired.
The problem with the first is that it requires all parsers known all schemas beforehand. I see a risk with backward compatibility after future extensions if that is required.
This is a little extreme - note that the 'standard' use case would be that all services would have knowledge of the base. This is the 'english' (so to speak) of web services. Since all elements derive from this base dialect, it is assumed that services will communicate and be assured that their messages are semantically correct. If you implement a service that absolutely requires a special namespace (e.g. 'nmlserialcompound' for some reason) this encoding will *only* make sense to other services that understand it. E.g. the services are now speaking a different language. Here is an example: <nmlserialcompound:relation freeks_special_attribute="true" /> If this was passed to a service that doesn't understand 'nmlserialcompound', the service could simply reject the entire element. It also could accept the foreign namespace, and attempt to parse the element with the only version of relation it happens to know about (nml). This would mean that the foreign attribute would most likely be ignored, but it still allows the message to be parsed. As I have said in previous exchanges - special dialects are useful if you intend to have specialized services and clients. From the perfSONAR/NMC world we are constructing the 'base' protocol that is really useless by itself - no services speak 'base'. We are also making a Measurement Archive protocol which is an extension of the base and uses concepts that only this type of service would care about. No services will speak this explicitly. Lastly there would be specific forms of data that a service would be expected to speak (e.g. throughput data, one way delay data, snmp data, etc.). These are the dialects that the services would be comfortable speaking. You can't simply send a request to utilization to a service that only speaks one way delay - even though the messages have the same structure, the semantics of what is being requested are slightly different. The service can attempt to parse the message in a base dialect, but most likely will reject things outright.
The problem with the second is that this fails if some schema (for whatever reason) includes a namespace where relation has a different meaning. Eg: family:relation or work:relation.
If you don't know the schema, you fail. This is how it has to be.
For this reason, including the extra nesting with<nml:relations> seems to me a relative simple solution to solve these problems.
After your entire mail, I am not exactly sure how you reached this conclusion. Lets say I had this: <nml:relations> <jason:relation> <!-- other things ... --> </jason:relation> </nml:relations> I am still in the situation as you described above, and now I have an extra element that really doesn't help me solve any problem. If you are still unclear on the concept of the namespaces I am happy to try to explain them more, but the exact things you are trying to solve with the addition of more elements can be done through namespaces and inheritance, NMC has done this for a while and it has worked well in practice in perfSONAR. Thanks; -jason