reasoning why XML namespaces aren't better.. they're just very verbose

This commit is contained in:
psyc://psyced.org/~lynX 2011-06-11 08:48:38 +02:00
parent 7ca1dd5198
commit 24412bee7d
1 changed files with 11 additions and 1 deletions

View File

@ -106,7 +106,7 @@ instead it allows for more addressing schemes than just PSYC.
** A new status updated activity
Example taken from http://onesocialweb.org/spec/1.0/osw-activities.html
You could call this XML namespace hell:
You could call this XML namespace hell.. :-)
#+INCLUDE: packets/activity.xml src xml
@ -122,6 +122,16 @@ We'll use the latter here:
#+INCLUDE: packets/activity.psyc src psyc
It's nice about XML namespaces how they can by definition never collide,
but this degree of engineering perfection causes us a lot of overhead.
The PSYC approach is to just extend the name of the method - as long as
people use differing method names, protocol extensions can exist next
to each other happily. Method name unicity cannot mathematically be ensured,
but it's enough to append your company name to make it unlikely for anyone
else on earth to have the same name. How this kind of safety is delivered
when using the JSON syntax of ActivityStreams is unclear. Apparently it was
no longer an important design criterion.
* Results
Parsing time of 1 000 000 packets, in milliseconds.