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