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

Hi Rob, fantastic stuff!

Perfect timing on this, as I had just noticed in RDFa 1.1 that they have added a simplified way to namespace in attribute values by introducing an @vocab attribute:
	http://www.w3.org/TR/2011/WD-rdfa-core-20110331/#A-vocab

This allowed them to switch from:

<div xmlns:foo="http://foo.example.org/vocab" typeof="foo:bar">
   <span property="foo:firstname">Phil</span>
   <span property="foo:lastname">Grasshopper</span>
</div>

to:
<div vocab="http://foo.example.org/vocab" typeof="bar">
   <span property="firstname">Phil</span>
   <span property="lastname">Grasshopper</span>
</div>

Which looks like a small change, but is much easier to write correctly and saves some keystrokes.


Perhaps we could do something similar, if we were to keep our metadata name/values in just attributes? (making up XML, borrowing <tag> from OSM)

With namespaces:
<meta xmlns:foo="http://foo.example.org/geodata" typeof="foo:poi">
  <tag k="foo:color" v="foo:blue"/>
</meta>

which might look in JSON something like:

{
  "meta":{
     "http://foo.example.org/geodata#color":"http://foo.example.org/geodata#blue"
  }
}

While simplifying it via @vocab, the XML would look like this:

<meta vocab="http://foo.example.org/geodata" typeof="poi">
  <tag k="color" v="blue"/>
</meta>

and the JSON maybe something like:
{
  "meta":{
     "vocab":"http://foo.example.org/geodata",
     "color":"blue"
  }
}

I suppose this type of system falls into the number 2 option you outlined of partially supporting namespaces.

-M
On May 26, 2011, at 12:40 AM, Rob Manson wrote:

> 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 12:48:06 UTC