Patch polymorphic / uncertain state type

[cboettig]

@hlapp I think this should now fix #171 / #172, but please verify. As mentioned in the commit note, this is just a really small fix to a bug in the S4 class definition of state, which defined symbol as integer type for standard states (e.g. symbol="1"), but as character type for polymorphic states (e.g. symbol="1 or 0").

Actually I believe this may actually be from what feels like an inconsistency in the NeXML schema.
In a standard state it appears to me that symbol attribute on a state is technically typed as a StandardToken, which looks to me to be defined as a restriction of xs:integer, which is I think why I typed the symbol as integer in the first place.

Meanwhile, in the NeXML schema defines symbol to be a xs:string in the case of a polymorphic state set, at least according to: http://www.nexml.org/doc/schema-1/characters/standard/#StandardUncertainStateSet

To me, this seems inconsistent, and is also the immediate cause of the bugs you identified, because R refuses to bind the integer symbol column to a character symbol column. Declaring symbol to always be a character string as I've done in the PR resolves the issue, but technically appears to be a deviation from the types declared by the schema itself.

cc'ing @rvosa for additional insight on this.

[hlapp]

Couple comments:

• That standard state symbols are typed as integers in NeXML seems appropriate given standard practice, though you might call it needlessly strict. That is, common exchange formats won't make it distinguishable whether the symbols in an integer-coded character column are type integer or string, and I doubt any R package for comparative analysis expects the states to be typed as integers or character vector so long as they can be turned into a factor. So I suspect there's no harm from typing these generally as character vectors as I suppose you do here. However, on input, symbols for standard states will be integers in all practical cases, even if the schema didn't enforce that.
• My approach to fixing the type mismatch problem was to simply add

  states <- states %>% dplyr::mutate_at(c("symbol"), as.character)

  and to do so only if there are polymorphic or uncertain states. This fixes the type problem too but without impact if there are no polymorphic and uncertain states. You don't think that's a good solution?

• This really only fixes the exception that's thrown, i.e., the issue reported in #171. It doesn't fix the other issues.

[cboettig]

@hlapp Thanks. I still don't follow the justification for the standard to type symbol attribute differently in polymorphic and non-polymorphic cases, that seems to be asking for trouble. But given that is what the standard says, yes, your solution is probably better. (I changed this first, assuming I had not followed the standard somehow, and only noticed later the standard really did type symbol as an integer.

Would you want to send a PR introducing

states <- states %>% dplyr::mutate_at(c("symbol"), as.character)

?

but this does resolve #171 , yes? (ERRROR Columnsymbolcan't be converted from integer to character). Just not all the issues in #172.

Yeah, I think #172 discusses this issue and also separate issues, might be easier to deal with the separate issues in separate issues.

[hlapp]

Yes I can do that.

[hlapp]

See #174.

[cboettig]

Closing in favor of #174