Re: [Standards] RFC: Make projects publish a DOAP file to get listed at xmpp.org

2017-08-20 Thread Jonas Wielicki
Hi,

Great work, I’ve been looking forward for that for quite some time now.

On Montag, 21. August 2017 05:08:32 CEST Emmanuel Gil Peyrot wrote:
> Please tell me whether you think it is a good idea, whether you would
> integrate it with your website/wiki/feature matrix/other, and any
> improvement you could think of!

What came into my mind is that the  tag should have some kind of 
machine-readable identifier for licenses which are generally recognized. There 
are projects out there which have machine-readable identifiers. The Debian 
project has some short names for licenses for their copyright file format [1], 
but unfortunately it lacks versioning of the licenses.

Another thing I’m concerned about is the comparison of version numbers. Is it 
assumed that the order of  tags matters? In that case, everything is 
fine. Otherwise, I imagine that interpreting the <{…xmpp-software}extension/> 
elements would not be trivial (it is unclear to a parser whether a version is 
greater than another version).

(Disclaimer: haven’t looked at your python script yet ☺)

kind regards,
Jonas


   [1]: https://www.debian.org/doc/packaging-manuals/copyright-format/1.0/
#license-short-name

signature.asc
Description: This is a digitally signed message part.
___
Standards mailing list
Info: https://mail.jabber.org/mailman/listinfo/standards
Unsubscribe: standards-unsubscr...@xmpp.org
___


[Standards] RFC: Make projects publish a DOAP file to get listed at xmpp.org

2017-08-20 Thread Emmanuel Gil Peyrot
Hi,

For quite a long time I’ve been trying to design a format that would
describe XMPP software, while being useful to most (all?) consumers of
this document, be it simple client listings like at xmpp.org, wikis
about projects wanting to stay up to date, feature matrices comparing
multiple implementations, or even authors who’d like to know who
implemented their specifications.

Attached are an example of an XMPP software (poezio, a client), and of
a consumer (xmpp.org, a simple website).

The format itself still has a lot of TODOs, most of which have been
reported to the DOAP project[1], while the XMPP specific parts still
lack a schema entirely.

The consumer Python script parses the file quite defensively, and then
generates the HTML you could have seen on xmpp.org (for the clients
page[1] and for a XEP page[2]).  The XEP page would require some
changes to the way XEPs are processed, since it generates the change
log itself, inserting implementations there.  Another way would be to
generate JavaScript code that would insert the DOM nodes at runtime.

There is also still the issue of having a place where all of these DOAP
URIs would be linked from, I think xmpp.org could act as such even for
projects unlisted from the main pages, but this remains to be decided.

Please tell me whether you think it is a good idea, whether you would
integrate it with your website/wiki/feature matrix/other, and any
improvement you could think of!

Thanks,

[1] https://github.com/ewilderj/doap/issues
[2] https://xmpp.org/software/clients.html
[3] https://xmpp.org/extensions/xep-0380.html

-- 
Emmanuel Gil Peyrot


poezio.xml
Description: XML document
#!/usr/bin/env python

from argparse import ArgumentParser
from datetime import datetime
from enum import Enum
from xml.etree.ElementTree import Element
import xml.etree.ElementTree as ET
import re

NUMBER_RE = re.compile(r'\d\d\d\d')
RFC_RE = re.compile(r'https://xmpp.org/rfcs/rfc(\d\d\d\d).html')
Type = Enum('Type', ['client', 'server', 'component', 'library'])
Status = Enum('Status', ['complete', 'partial', 'started', 'interested'])

TABLE_TEMPLATE = '''

  
Project Name
Platforms
  
  
%s
  

'''

def parse_args():
parser = ArgumentParser(description='DoaP parser, with XMPP stuff added')
parser.add_argument('files', nargs='+', metavar='FILE', type=open, help='The DoaP file(s) to parse')
return parser.parse_args()

class DoapParseError(Exception):
pass

class Extension:
#__slots__ = ('_xml', 'number', 'status', 'version', 'since', 'note')

def __init__(self, xml: Element):
self._xml = xml
self.number = self.parse_number()
self.note = self.parse_note()
self.since = self.parse_since()
self.status = self.parse_status()
self.version = self.parse_version()

def __repr__(self):
return 'XEP-%s (%s, version %s, since %s%s)' % (
self.number,
self.status.name,
self.version,
self.since if self.since is not None else 'forever',
', ' + self.note if self.note is not None else '')

def parse_number(self):
number = self._xml.get('number')
if number is None or not NUMBER_RE.match(number):
raise DoapParseError(f'invalid number {number} for extension.')
return number

def parse_status(self):
try:
return Status[self._xml.get('status')]
except KeyError:
raise DoapParseError('invalid status for XEP-{self.number}.')

def parse_version(self):
version = self._xml.get('version')
if version is None:
raise DoapParseError(f'invalid version for XEP-{self.number}.')
return version

def parse_since(self):
return self._xml.get('since')

def parse_note(self):
return self._xml.get('note')

class Doap:
ALLOWED_OS = ('Android', 'Browser', 'iOS', 'Linux', 'macOS', 'Windows')

#__slots__ = ('_xml', 'name', 'created', 'homepage', 'os', 'xmpp')

def __init__(self, xml: Element):
self._xml = xml
self.name = self.parse_name()
self.created = self.parse_created()
self.homepage = self.parse_homepage()
self.os = self.parse_os()
self.xmpp = self.parse_xmpp()

def parse_name(self):
name = None
try:
name = self._xml.find('{http://usefulinc.com/ns/doap#}name').text
except AttributeError:
print('Warning: no name defined for project.')
else:
if name is None:
print('Warning: no name defined for project.')
return name

def parse_created(self):
created = None
try:
created = datetime.strptime(self._xml.find('{http://usefulinc.com/ns/doap#}created').text, '%Y-%m-%d')
except ValueError:
print('Warning: invalid creation date for project.')
except TypeError:
print('Warning: invalid creation date for project.')
  

Re: [Standards] LAST CALL: XEP-0186 (Invisible Command)

2017-08-20 Thread Evgeny Khramtsov
Sat, 19 Aug 2017 21:17:28 -0600
Peter Saint-Andre  wrote:

> I'll make the relevant fixes soon!

My few cents.

Section 3.1:

> The  element MUST include a 'probe' attribute ...
> The default logical value is FALSE ...

This doesn't make sense: a required attribute cannot have a default
value because it's always present. We should either make it optional
or remove "default logical value" from the spec.

> Although the default value is false (thus protecting the user from
> leaking presence information), the client SHOULD always include the
> 'probe' attribute.

Contradiction: MUST vs SHOULD
___
Standards mailing list
Info: https://mail.jabber.org/mailman/listinfo/standards
Unsubscribe: standards-unsubscr...@xmpp.org
___