[Nml-wg] XML syntax for NML relations

Tue Aug 23 11:45:12 CDT 2011

Stepping up a level here, what is the benefit of subclassing a relation? They're simple elements, just a type and pointers to one or more other elements. How would the subclass improve things? You could only very slightly change semantics while retaining backwards compatibility with the base namespace (at most 1 element, more than 1, etc.). I see it as similar to subclassing 'name' or 'description' or whatever.

Cheers,
Aaron

On Aug 23, 2011, at 12:36 PM, Jason Zurawski wrote:

> Hi Freek;
> 
> Answers inline:
> 
> On 8/23/11 11:15 AM, thus spake Freek Dijkstra:
>> Hi Jason,
>> 
>> I don't claim to be an NM expert like yourself, but have of course read
>> the NM message specification and the examples in the PerfSONAR-PS code.
>> 
>> Jason Zurawski wrote:
>> 
>>> For example:
>>> 
>>> a)
>>> <relation type="something">
>>>    <link />
>>>    <link />
>>> </relation>
>>> 
>>> vs.
>>> 
>>> b)
>>> <somethingrelation>
>>>    <link />
>>>    <link />
>>> </somethingrelation>
>>> 
>>> vs
>>> 
>>> c)
>>> <something:relation type="something">
>>>    <link />
>>>    <link />
>>> </something:relation>
>> 
>> vs
>> 
>> d)
>> 
>> <relations>
>>   <somethingrelation>
>>     <link />
>>     <link />
>>  </somethingrelation>
>> </relations>
>> 
>> (where every direct child element of<relations>  MUST be a subclass of
>> the base class "relation").
> 
> I fail to understand why this is better than using a alternate namespace 
> on existing element from base. It is unclear to me how you propose to 
> facilitate this 'subclass' idea using the avalable tools and constructs 
> of XML.  You have introduced two new elements: 'relations' and 
> 'somethingrelation', and both have no relationship to the base class 
> that I am able to tell.  If you are proposing that both of these *be* 
> the base class, than my argument is that you will need to enumerate all 
> possible children of 'relations' beforehand, otherwise there is no 
> longer any expected extensibility.
> 
> In my opinion, all your modifications have does is add complexity (e.g. 
> now there is a spurious new 'level' by requiring that people use 
> 'relations') and the notion of 'subclassing' that still cannot be 
> enforced via syntactic means.  It is not clear to me how you intend to 
> enforce 'somethingrelation' having a relationship to 'relation' with 
> just XML, these are completely different elements and XML isn't fully 
> featured enough to allow what you want to do.  This last point destroys 
> the aspect of extension, and would force new designs to modify the NML 
> base each time a new relationship is constructed.
> 
>>> I would argue that a) is our base, it is generic and minimal.
>> 
>> I'm well aware that this is in use in NMC, and served 2 out of the 3
>> requirements, which is pretty good for most purposes.
>> 
>>> Schema is schema, you can construct whatever type of validation system
>>> you wish to implement.  I would question how far you would want to take
>>> this exercise because there are tradeoffs that sacrifice other desirable
>>> qualities.  My statement from prior conversation still stands - if you
>>> wish to do strict syntactic validation, to the point of trying to use
>>> the parser as a semantic analyzer as well, you give up a portion of #1;
>>> this is the tradeoff that must be considered.
>> 
>> All I was trying to suggest is that it occurs to me that d) would serve
>> 3 out of the 3 requirements,
> 
> See my argument above, based on your proposal is not clear to be how you 
> intend to foster extension with the d).  You are introducing elements 
> that have no relationship to each other.  If I am go to on what you have 
> provided, I am left to think that you are destroying the ability to 
> extend by creating single use elements that cannot be extended.   You 
> get strict validation, but all use cases for the relationships must be 
> known by the base.
> 
> Perhaps your example makes perfect sense to you in, but I am not seeing 
> any clear benefit.
> 
>> and I was asking if someone on the list saw
>> any serious problems with it. The only problems I have heard so far were
>> that it (1) deviated from the solution in use for NMC, and (2) added one additional level of nesting to the XML messages. Both
>> arguments have their merits, but have not convinced me for choosing a)
>> over d).
>> 
>> However, you just pose a new argument:
>> 
>>> The b) option is the creation of a new element, something that *does
>>> not* derive from the base, and therefore cannot be cast into something
>>> different.
>> 
>> I must disagree.
>> 
>> In the case of b) and d) above, the schema definition file should define
>> "somethingrelation" as a subclass of "relation". (and I presume that
>> they are). In that case, "somethingrelation" is derived from the base.
> 
> Please provide an example of how you intend to this in either RNC or XML 
> Schema.  Please be complete in your example so we can critique it, if 
> you need help in using MSV/Jing/Trang, see this README:
> 
> http://anonsvn.internet2.edu/svn/nmwg/trunk/nmwg/schema/README.txt
> 
> My statement on this matter is born out of experience, and I am happy to 
> admit my faults and errors if you have some proof of operational 
> soundness in doing this approach.
> 
>>> The c) option is an extension namespace of the a) element.
>> 
>> In the above examples a), b) and c), I have no preference as to which
>> namespace the elements belong.
>> 
>> The issue on whether the type should be a value in an attribute (a), or
>> in the name of the element (b and d) seems orthogonal to the choice of
>> namespace (b versus c).
> 
> I am not following your argument here at all.  I believe there is still 
> a very serious disconnect between us and perhaps this is where it comes 
> from.
> 
> Based on your statements above, you want to allow the concept of 
> subclassing for the 'relation' element, and you propose to do this by 
> allowing 'somethingrelation' and 'somethingrelation2', etc. have this 
> property.  I am claiming it does not work this way, and that the 
> features you wish to achieve (subclassing) must be done using the 
> alternative namesapces I have been describing for more than a month.
> 
> To summarize:
> 
> Base = nml:relation
> Something sub class = something:relation
> Something 2 sub class = something2:relation
> 
> The elements are the same, the namespaces are different.  If you want to 
> call them 'subclasses', so be it, but recall that we are not dealing 
> with a programming language here.  We are dealing with a markup language 
> that probably was *never* intended to do all of the fully featured 
> things that NMC or NML wish to do.
> 
> I am well aware of your dislike of the 'type' element, you clearly 
> stated this in SLC, and most of these emails.  Whatever your reasons 
> are, I am only going to note that your attempt to defeat it using the 
> current approach of adding new elements is not working to convince me. 
> I see clear extensibility problems, and I will continue to tell you 
> about them each time you bring them up.
> 
>>>> 3. Parsers should be able to recognise an unknown relation type as a
>>>> relation subclass (rather then simply an unknown element)
>>> 
>>> Every parser is different in this respect, and I am not going to be able
>>> to give you a concrete answer.
>> 
>> [... long and well written argument skipped ...]
>> 
>>> Hope this all helps;
>> 
>> Thanks for your long answer, it was helpful.
>> 
>> It occurs to me that an "strict syntactic checking" may entail two
>> different concepts: a very strict schema (where any message with unknown
>> elements is invalid and thus rejected by parsers) and a detailed scheme
>> which does list all known details (but with provisions for unknown
>> elemet (where parsers are able to parse the elements it is aware of, but
>> ignore the elements it does not know).
>> 
>> I'm much in favour of the second concept; you seem to argue about the
>> first concept (which I personally (also?) do not like) in your email.
> 
> You are entitled to do whatever you believe to be the correct answer. 
> This group does not need to follow the NMC method if you feel it is 
> fatally flawed, and I will still encourage you to start fully 
> enumerating your proposed new approach beyond simple snippets of XML.
> 
>> To bring in the NM analogy, I very much like the RNC files in the
>> perfSONAR-PS code, which is detailed and yet still flexible.
>> I do not like the (unused?) WSDL files in the MDM code, which only
>> define the message type, but not how it looks like.
>> 
>> Compare the RNC files from your previous email to
>> http://anonsvn.internet2.edu/svn/nmwg/trunk/nmwg/perl/server/NMWG.wsdl
> 
> I am going to stop you there and note this is more than 7 years old, 
> represents a demo service that is no longer in development, and is not 
> maintained by anyone.  It is not the best thing to use for a comparison.
> 
>> I would even favour something which is even more detailed then the RNC
>> files (and I agree that this is just a personal preference which we
>> indeed have already debated enough just yet :) ).
>> 
>>> If an unknown element comes in, many parsers will [...]
>> 
>> Your original sentence stated "reject the whole message".
>> The bottom line is that we should DEFINE in the NML specification how
>> parsers should behave in that case.
>> 
>> I think we should add this item on the todo list for this WG and solicit
>> input from any contributor on the list to propose such specification.
>> 
>> Jason, would you agree this is a valid todo item for the group?
> 
> I do not agree, because crafting a new parser seems to be unnecessary 
> busy work without any clear advantage for the group.  This is an effort 
> to create a standard, and I would think that incorporating existing 
> technology when possible is a positive step.  Given that, and peaking 
> for my time requirements only - I cannot contribute any help to do this.
> 
> If you still feel this is the direction you wish to take, I look forward 
> to reviewing what you are able to produce as an alternative approach to 
> what is on the table right now.
> 
> Thanks;
> 
> -jason
> 
> _______________________________________________
> nml-wg mailing list
> nml-wg at ogf.org
> http://www.ogf.org/mailman/listinfo/nml-wg

Summer 2011 ESCC/Internet2 Joint Techs
Hosted by the University of Alaska-Fairbanks
http://events.internet2.edu/2011/jt-uaf

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://www.ogf.org/pipermail/nml-wg/attachments/20110823/d409729d/attachment-0001.html 