XSF Editor Team - 2020-05-23

  1. stpeter has joined
  2. stpeter has left
  3. stpeter has joined
  4. stpeter has left
  5. bear has left
  6. stpeter has joined
  7. soul has joined
  8. stpeter has left
  9. bear has joined
  10. stpeter has joined
  11. stpeter has left
  12. stpeter has joined
  13. stpeter has left
  14. soul has left
  15. stpeter has joined
  16. stpeter has left
  17. soul has joined
  18. stpeter has joined
  19. stpeter has left
  20. stpeter has joined
  21. bear has left
  22. stpeter has left
  23. Tobi has joined
  24. stpeter has joined
  25. bear has joined
  26. stpeter has left
  27. stpeter has joined
  28. stpeter has left
  29. stpeter has joined
  30. stpeter has left
  31. stpeter has joined
  32. stpeter has left
  33. stpeter has joined
  34. stpeter has left
  35. stpeter has joined
  36. stpeter has left
  37. stpeter has joined
  38. stpeter has left
  39. stpeter has joined
  40. stpeter has left
  41. pep. Does updating the registrar entries of a XEP mandate a version block
  42. stpeter has joined
  43. stpeter has left
  44. flow pep., do you update the registrar entries without a textual change of the XEP?
  45. stpeter has joined
  46. pep. Well depending on the XEP, it might just make sense to only update the registrar..
  47. pep. I did update the sole exapmle here though
  48. pep. So probably at least requires a patch release
  49. flow pep., which change are we discussing?
  50. pep. https://github.com/xsf/xeps/pull/949/files
  51. flow ohh that's a good one
  52. flow I first ask myself if data form registry entries also come with <required/>
  53. flow so right now, one could argue all the existing fields in the registry submission of xep157 are optional
  54. flow and the new field you add is also optional
  55. flow so it is a backwards compatible change
  56. flow it would clearly require a version block if it was a backwards incompatible change
  57. flow but nevertheless it basically adds a new thing (akin to attribute element4) on the protocol layer, so i'd say a version block would be required
  58. flow even if it would not be required it would be nice
  59. flow plus it would certainly be nice if you also extend the example
  60. flow and even add a textual description for that field
  61. flow because I ask myself if I could parse the text in that field as uri
  62. flow i.e., if this field is required to contain only valid URIs
  63. flow hmm the last one is probably unrelated to your concrete change
  64. flow oh, there is no trace of <required/> in the xsf registry, so either it is not expected to be included in the registration submission, which I would find strange, or, we there was simply never a required field registered
  65. pep. so.. version block? :p
  66. stpeter has left
  67. pep. What do you mean "extend the example"? Don't I already do that?
  68. flow pep., ahh sorry, for some reason I only saw the diff in the registry submission
  69. pep. hmm, how do I even make sure it contains valid URIs.. That would be good to have yes
  70. flow pep., well you could specify it in text, idally we would extend xep122 for that, but that can be done later on
  71. flow uh wait
  72. flow xep122 has support for xs:anyURI
  73. pep. So how would that work? Can I say that in the PR?
  74. flow hehe, that's probalby newland. similar to <required/> I can't find registry entries with xep122 annotations. But that doesn not mean that it should not go in the registry, it probably just means that nobody bothered or did it
  75. flow i personally think it belongs in the registry information, but not in the example, as the example shows a data form of type 'result'
  76. flow and you have the xep122 annotations usually in data forms of type 'form'
  77. flow and you have the xep122 annotations only make sense in data forms of type 'form'
  78. flow and xep122 annotations only make sense in data forms of type 'form'
  79. stpeter has joined
  80. stpeter has left
  81. stpeter has joined
  82. stpeter has left
  83. stpeter has joined
  84. stpeter has left
  85. stpeter has joined
  86. stpeter has left
  87. lnj has joined
  88. Guus has left
  89. Guus has joined
  90. Guus has left
  91. Guus has joined
  92. lnj has left
  93. lnj has joined
  94. bear has left
  95. lnj has left
  96. lnj has joined
  97. bear has joined
  98. lnj has left
  99. lnj has joined
  100. lnj has left
  101. lnj has joined
  102. lnj has left
  103. lnj has joined
  104. lnj has left
  105. lnj has joined
  106. lnj has left