File this under very, very minor nit that I don't really care too much about, but should we call this thing something other than chord? Technically, it really isn't Chord anymore, but sort of an enhancement to it, and someone might want to use/implement a version that really is regular chord for some reason. Chord-P2PSIP or something?
David (as individual) On Sat, Mar 6, 2010 at 8:22 PM, Cullen Jennings <[email protected]> wrote: > > Fixed the < on the turn-density - no idea how that got there thanks. > > The XML needs to be extensible in certain ways and we use namespaces for > that. The ext: namespace is just a bogus extension to test extensibility. > Code should allow that to be there in a config file even thought it is not a > "real" extension. The chord namespace is a real extension and defines the > parameters that are specific to the chord DHT plug in. > > I've been validating these in Oxygen and they seem to be working fine but > it's really easy to make a mistake with them. Can you point out what is wrong > with the relaxNG or xml? > > And thanks for all the testing on this. > > Cullen > > > On Feb 18, 2010, at 9:23 AM, neil.young wrote: > >> Additional information: >> If I remove all elements, tagged with "chord:" and "ext:" from the XML >> everything is fine. But I believe this is not the intention. >> Regards >> >> >> neil.young schrieb: >>> 10.1: >>> >>> I'm unable to generate a proxy class from the XML. Normaly I'm using >>> xsd.exe to convert plain xml to an xsd, if the xsd isn't provided. The >>> schema then is converted to proxy class, which might easily be used in C# >>> code. This works with several XML based information contents in 3GPP >>> projects, but not with RELOAD. >>> >>> Furthermore the XML is syntactically incorrect in the line containing >>> "<turn-density> 10 </turn-density><" >>> >>> The final "<" has to be removed. >>> >>> I was taking this xml and fed it to xsd.xml >>> >>> c:\xsd reload.xml >>> >>> The resulting 3 xsd files (reload.xsd, reload_app1.xsd, reload_app2.xsd) >>> could not be converted to a wrapper class by >>> >>> c:\xsd reload.xsd /language:cs /classes >>> >>> The error is: >>> Schema validation warning: >>> urn:ietf:params:xml:ns:p2p:config-ext1:example-extention-Element not >>> declared. Line 18, position 16. >>> Schema validation warning: >>> urn:ietf:params:xml:ns:p2p:config-chord:chord-ping-interval-Element not >>> declared. Line 19, position 16. >>> Schema validation warning: >>> urn:ietf:params:xml:ns:p2p:config-chord:chord-update-interval-Element not >>> declared Line 20, position 16. >>> Schema validation warning: Das >>> urn:ietf:params:xml:ns:p2p:config-ext1:example-kind-extention-Element not >>> declared. Line 56, position 34. >>> >>> Although this is just warnings, the code generation fails too in the first >>> step: >>> Error: Error generating classes for schema 'reload'. >>> - 'urn:ietf:params:xml:ns:p2p:config-ext1:example-extention' missing. >>> >>> Regards >>> >>> >>> neil.young schrieb: >>>> 5.3.1.1 >>>> >>>> <quote> >>>> Thus, the 3-byte value >>>> "Foo" would be encoded as: 03 46 4f 4f. >>>> </quote> >>>> >>>> In fact it should be "encoded" as "03 46 6f 6f", or it should be named >>>> "FOO" :) (BTW: Those kind of errors in your draft is on the level I'm able >>>> to discover... :)) >>>> >>>> Question behind: May I assume, that every "opaque" value, as far as no >>>> explicitly determined in length, is preceded by a length byte (or more >>>> bits) on the wire? >>>> >>>> Regards >>>> >>> >> >> _______________________________________________ >> P2PSIP mailing list >> [email protected] >> https://www.ietf.org/mailman/listinfo/p2psip > > > Cullen Jennings > For corporate legal information go to: > http://www.cisco.com/web/about/doing_business/legal/cri/index.html > > > > _______________________________________________ > P2PSIP mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/p2psip > _______________________________________________ P2PSIP mailing list [email protected] https://www.ietf.org/mailman/listinfo/p2psip
