ACTION-77 / ISSUE-27: What issues arise from using namespaces in the XML serialization?

Here is the summary of my evaluation of the use of namespaces in the
different serialisation formats that the POI standard may support.

I'll look forward to feedback, comments and discussion.


roBman


See #ACTION77 / #ISSUE27
http://www.w3.org/2010/POI/track/actions/77
http://www.w3.org/2010/POI/track/issues/27 

NOTE: I've used generic wikipedia links as they are aggregates of the
other useful origin links on each of the topics.  They are not intended
to be credible sources in and of themselves.


Question:
What issues arise from using namespaces in the XML serialization?
XML itself supports the xmlns usage, but by using this in the POI
standard examples this then excludes the use of these in JSON or any
other formats that may be explored.
http://en.wikipedia.org/wiki/Namespace 
http://en.wikipedia.org/wiki/XML_namespace


Review of use of namespaces:
        name            format    supports namespaces
        json            json      no
        http://en.wikipedia.org/wiki/JSON
         
        xml             xml       yes
        http://en.wikipedia.org/wiki/XML 
        
        georss(rss)     xml       no
        georss(atom)    xml       yes
        http://en.wikipedia.org/wiki/GeoRSS
        
        geojson         json      yes-ish
        http://en.wikipedia.org/wiki/GeoJSON 
        NOTE: There are examples of @namespace usage in the geojson
        wiki...but the standard spec itself does not seem to address
        this.
        
        kml             xml       yes
        http://en.wikipedia.org/wiki/KML 
        
        gml             xml       yes?
        http://en.wikipedia.org/wiki/Geography_Markup_Language 


Examples of common namespaces used:
        - dublin core http://en.wikipedia.org/wiki/Dublin_Core 
        - atom http://en.wikipedia.org/wiki/Atom_rss 
        - geo http://en.wikipedia.org/wiki/Geo_%28microformat%29 


What strategies could we apply:
Here is a simple summary of the 3 key strategies we could pursue for
this issue and a very brief outline of the pros/cons.  Obviously this is
a very simplified summary of this issue and much more debate on the
topic is required.

1. Do not support namespaces
Simply exclude the use of namespaces altogether.

        pros:
        This simplifies the expression in different serialisation
        formats and removes this issue altogether.
        
        cons:
        This means we do not benefit from any of the existing working in
        common domains where pre-defined data models have been well
        thought out and tested.  This also makes the POI standard a very
        static standard with extension only possible through revision.


2. Support namespaces
Adopt the use of namespaces either in full or partially.

        pros:
        This allows the POI standard to re-use existing common data
        models from related fields and allows it to be easily extended
        as new data models are defined and adopted.
        
        cons:
        This makes the definition of the POI standard more complex and
        time consuming.  The consistent use of namespaces across XML and
        JSON has not really been achieved in any previous body of work
        and is obviously very challenging.


3. Hardwire common datastructures
Simply take the data models used in common or popular namespaces and
pre-define their use in the POI standard.

        pros:
        This is a simply and achievable hybrid of the two approaches
        listed above.  It has the benefit of "standing on the shoulders
        of giants" while make the problem more tractable.
        
        cons:
        This makes the POI standard static and therefore can only be
        extended through revision.

Received on Thursday, 26 May 2011 04:40:41 UTC