Accessing Segments and Scenarios

Mar 11, 2015 at 1:41 PM
Hi Jeff,

I was wondering whether it's possible to access xbrl segments and scenarios. Those are declared as internal and I wouldn't know how to access them.

Thanks in advance
Chr_96er
Mar 11, 2015 at 1:52 PM
Hello! Can you tell me more about why you would like to access segments and scenarios? Originally, I kept them internal so that I could use and process them when I added XBRL Dimensions. If you're looking for these items for a separate reason, please let me know and I will look into exposing that information.
Mar 12, 2015 at 11:25 AM
Thanks for the fast answer. Actually I'm not sure anymore whether this is really necessary. I'll let you know, in case it becomes relevant again.
May 31, 2015 at 11:22 PM
Edited Jun 1, 2015 at 8:06 AM
I am currently considering using gepsio to parse xbrl instanace documents, but would require data stored within the segment section of a context.

It appears that the would be some difficulty exposing this data in a using the object model as the definition of a segment for xbrl is a block of xml which cannot be xbrl elements. Specifically I was trying to parse xbrl as explained here.

I have started patching gepsio to model the data as seen in the above example but it will probably not work for other taxonomies.
Jun 1, 2015 at 4:52 PM
You are correct: this information is in XML fragments and is used by other technologies. Specifically, information related to XBRL Dimensions is stored beneath these elements. Gepsio keeps references to these nodes, and the general idea was to make use of them when Dimensions was implemented.

Is there a general need, beyond Dimensions, to make these nodes visible?
Jun 1, 2015 at 11:13 PM
As noted here under the definition for segment, the documents that I would be processing contain an additional piece of identifier stored in the segment for each dimension.
Additionally, these extra identifiers are not simply explicitMember nodes, but nested under a typedMember node, but at the end of the day effectively just xml.
Jun 2, 2015 at 1:35 PM
What would you like to see from Gepsio with regards to these nodes? Would you like a reference to the parent node so you can access the children? Or would you like a reference to a string that contains the inner XML? Or something else?
Jun 4, 2015 at 8:56 AM
I think the most obvious and flexible would be to expose the parent Xml node so that the user can parse the segment data themselves.
For my own use I have added a Segment class which is basically Name, Dimension, Value and a list of Child Segments. Currently this is working for my purposes, but this could just as easily be moved to the consuming application and have it parse the segment from the source xml.
Jun 4, 2015 at 1:30 PM
That's fair. My only concern is that exposing the XmlNode would force people to use a specific XML technology. For example, XmlNode is a part of the System.Xml namespace, and would be a burden for people who would prefer to use LINQ, XNode objects, and the System.Xml.Linq namespace. Currently, Gepsio has the XML processor behind an interface so that these namespace details are abstracted from the other layers. If Gepsio then decides, for whatever reason, to migrate from XmlNode/System.Xml to XNode/System.Xml.Linq, then the changes would be isolated.

There are, then, a few options here:
  1. Expose the underlying XmlNode and hope that no one using XNode/System.Xml.Linq will be bothered
  2. Expose Gepsio's XML public interface, expose an INode, and let callers use the Gepsio XML interface to process the data
  3. Implement XBRL Dimensions, which is in the roadmap anyway, process the segment nodes internally, and expose the dimensions data as a part of the object model
  4. ... Something I haven't thought of yet ...
Good discussion!