While going through the definition link base of a taxonomy, i found that a few domain members were present in two separate dimensions. Eg. Dim A contains domain Dom1 with members m1, m2,m3,m4. And Dim B contains domain dom2 with members m2,m3,m4. The issue is that it may lead to conflicting context names (even though the segment part of the contexts will be different).
The format of the context name is 'periodInformation_domainMember'. I need to use different dimensions for different sections of my report. So my basic question is how do i form context names?
I hope i have conveyed myself properly.
Appreciate any help... :)
use "Period Information + Dimension + member name" for making context names unique.....
You have to check the uniqueness based on the child nodes of <period> tag and child nodes of the <segment> tag... here in segment; if segment is present then each xbrldi:explicitMember has dimension in its attribute and member in its value...
...more: http://www.xbrl.org/Specification/XBRL-RECOMMENDATION-2003-12-31+Corrected-Errata-2005-04-25.htm#_4.7
What if there were multiple dimensions? Playing devil's advocate, what if you have dimensions with the same local name but in different namespaces? The only way to guarantee a unique name is to use the whole content of the context - which is ridiculous.
I've seen recommendations by regulators requiring filings in XBRL that 'Semantics SHOULD NOT be expressed...' in a context id and it is '..recommended to keep it as short as possible...'
The simplest solution is to pick unique names that that have nothing to do with the contents - for example c-1, c-2 etc.
The syntax of the XBRL is unimportant, it's just an implementation detail.
Related
Example: What is the difference between :
List<UserCompany> findByCompany_IdAndCompany_IsActivated(params)
and
List<UserCompany> findByCompanyIdAndCompanyIsActivated(params)
There is no difference if your model is unambiguous with respect to field names.
List<UserCompany> findByCompanyIdAndCompanyIsActivated(params) -
this first thinks that companyId and companyIsActivated are properties within UserCompany and tries to find them if fails
it then thinks that UserCompany has a field Company - which is another class and Company has field - Id and IsActivated and tries to find them
Where as the below thing
List<UserCompany> findByCompany_IdAndCompany_IsActivated(params)
assumes directly that UserCompany has a field Company - which is another class and Company has field - Id and IsActivated and tries to find them
From the spring documentation
Property expressions :---
Property expressions can refer only to a direct
property of the managed entity, as shown in the preceding example. At
query creation time you already make sure that the parsed property is
a property of the managed domain class. However, you can also define
constraints by traversing nested properties. Assume Persons have
Addresses with ZipCodes. In that case a method name of
List findByAddressZipCode(ZipCode zipCode); creates the
property traversal x.address.zipCode. The resolution algorithm starts
with interpreting the entire part (AddressZipCode) as the property and
checks the domain class for a property with that name (uncapitalized).
If the algorithm succeeds it uses that property. If not, the algorithm
splits up the source at the camel case parts from the right side into
a head and a tail and tries to find the corresponding property, in our
example, AddressZip and Code. If the algorithm finds a property with
that head it takes the tail and continue building the tree down from
there, splitting the tail up in the way just described. If the first
split does not match, the algorithm move the split point to the left
(Address, ZipCode) and continues.
Although this should work for most cases, it is possible for the
algorithm to select the wrong property. Suppose the Person class has
an addressZip property as well. The algorithm would match in the first
split round already and essentially choose the wrong property and
finally fail (as the type of addressZip probably has no code
property). To resolve this ambiguity you can use _ inside your method
name to manually define traversal points. So our method name would end
up like so:
List findByAddress_ZipCode(ZipCode zipCode);
Underscore is reserved character which allows you to point the right object to construct jpa query. It's used only with nested objects. For example if you would like to query by ZipCode inside Address inside you Company object.
More information can be found here
We are using SQLite property database to get information about object's properties. The problem we are facing with is property identification. For each property we have:
id: looks like it is just an autoincremental id and it can be used to
identify property between two versions of the same model
name: for .rvt models it is mostly unique, but there are some duplications
sometimes (for example the same property with different flags,
readonly and not); for .ifc files it is not unique at all
category + displayName: the problem with this
fields is that after using design automation API (to change and
re-save model) category/displayName can be translated into English
(but initially they can be, for example, in German)
Now we are using the combination of 'name + category + displayName' to identify the property, but it is not the solution, because this combination still is not unique in some rare cases (it is data lost for us) and it doesn't solve the problem with property names translation using Design Automation API.
Any ideas how to identify properties will be helpful! Thanks
For a given element, the externalId should be unique within that model (at the model level, the urn is unique). There is no unique identification for properties.
I'm interested in understand this workflow better, are you able to have a quick talk? Please use this link to book a time.
I have a dataset with multiple observations by participant. Participants are denoted by id. To account for this in the cross validation process, I add blocking = factor(id) to makeClassifTask() and blocking.cv = TRUE to makeResampleDesc(). However, if I leave id in the dataset, it will be used as a predictor. My question is: How do I correctly use blocking? My take would be to create a new variable, e.g. participant.id (outside of the dataset), next to remove id from the original dataset and then to use blocking = factor(participant.id), but I am not sure if this is the correct way to handle blocking.
Rather than supplying a variable for blocking you can provide a custom factor vector that specifies the observations which belong together. This is also shown in the tutorial.
This way you do not need to have the variable "participant.id" in the dataset.
Also make sure that you really want to use "blocking". Did you have a look at "grouping" already? The differences between both are also described in the linked tutorial section.
I am trying to find only the current period concepts and facts for the three main financial statements. The goal is to be able to iterate through filings of different companies in different periods.
Using Ebay 2017 10-k as an example.
For concepts that capture YoY change, like those in income statement and statement of cash flows, I can use context found in any of the dei tags, for example:
<dei:DocumentFiscalYearFocus contextRef="FD2017Q4YTD" id="Fact-2E3E1FD4D81352F693510AE035FDC862-wk-Fact-2E3E1FD4D81352F693510AE035FDC862">2017</dei:DocumentFiscalYearFocus>
dei:DocumentFiscalYearFocus tag is required, and its context "FD2017Q4YTD" is also found in all IS and SCF period end concepts, so that's easy.
However, balance sheet concepts use a different context:
<us-gaap:CashAndCashEquivalentsAtCarryingValue contextRef="FI2017Q4" decimals="-6" id="d15135667e874-wk-Fact-3E4A0A2B272B59DE9DAF004097ECF968" unitRef="usd">2120000000</us-gaap:CashAndCashEquivalentsAtCarryingValue>
Any idea how to identify the "FI2017Q4" context (or otherwise find current period balance sheet concepts)?
The XBRL document instance you are viewing contains one or more schemaRef elements, each of which loads an XBRL taxonomy, or data dictionary, for the XBRL instance. Somewhere, within that reference graph of files (and there could be several files), is the definition of each context. The definition will look something like this:
<context id="CONTEXT_ID_NAME">
<!-- ... child elements appear here ... -->
</context>
If you can find the <context> element with an attribute of id that matches the contextRef you're interested in, then you've found what you're looking for. In your case, you're looking in the related XBRL taxonomy files for something that says <context ID="FD2017Q4YTD"> and <context ID="FI2017Q4">.
The child elements of the <context> element describes the dates for the context. There are two types of XBRL contexts:
instant, which specifies a context with a single date
period, which specifies a context with a start date and an end date
The child elements of the <context> element will describe which type of context being described.
This work is all manually doable, but it might be best to use XBRL processing software, which will perform all of this work for you.
The value of the contextRef attribute is purely an identifier that references a context definition elsewhere in the document. Using the eBay example, you'll find this context definition:
<context id="FI2017Q4">
<entity>
<identifier scheme="http://www.sec.gov/CIK">0001065088</identifier>
</entity>
<period>
<instant>2017-12-31</instant>
</period>
</context>
The value in the "instant" element is what tells you what date facts associated with this context relate to.
In order to properly understand the XBRL facts, you need to fully understand the associated contexts. There may be other information, such as additional dimensions, defined here.
I'd strongly recommend working with an existing XBRL processor that will resolve the contextual information for you, such as the open source Arelle processor, or the API provided by XBRL US.
One possible approach to working with XBRL data is to use a processor that converts data to the newer xBRL-JSON format, which provides fact objects with all contextual information fully resolved.
I have been digging through IBM knowledge center and have returned frustrated at the lack of definition to some of their scripting interfaces.
IBM keeps talking about a containment path used in their id definitions and I am only assuming that it corresponds to an xml element within file in the websphere config folder hierachy, but that's only from observation. I haven't found this declared in any documentation as yet.
Also, to find an ID, there is a syntax that needs to be used that will retrieve it, yet I cannot find a reference to the possible values of 'types' used in the AdminConfig.getid(...) function call.
So to summarize I have a couple questions:
What is the correct definition of the id "heirachy" both for fetching an id and for the id itself?
e.g. to get an Id of the server I would say something like: AdminConfig.getid('/Cell:MYCOMPUTERNode01Cell/Node:MYCOMPUTERNode01/Server:server1'), which would give me an id something like: server1(cells/MYCOMPUTERNode01Cell/nodes/MYCOMPUTERNode01/servers/server1|server.xml#server_1873491723429)
What are the possible /type values in retrieving the id from the websphere server?
e.g. in the above example, /Cell, /Node and /Server are examples of type values used in queries.
UPDATE: I have discovered this document that outlines the locations of various configuration files in the configuration directory.
UPDATE: I am starting to think that the configuration files represent complex objects with attributes and nested attributes. not every object with an 'id' is query-able through the AdminConfig.getid(<containment_path>). Object attributes (and this is not attributes in the strict xml sense as 'attributes' could be nested nodes with a simple structure within the parent node) may be queried using AdminConfig.showAttribute(<element_id>, <attribute_name>). This function will either return the string value of the inline attribute of the element itself or a string list representation of the ids of the nested attribute node(s).
UPDATE: I have discovered the AdminConfig.types() function that will display a list of all manipulatible object types in the configuration files and the AdminConfig.parent() function that displays what nodes are considered parents of the specified node.
Note: The AdminConfig.parent() function does not reveal the parents in order of their hierachy, rather it seems to just present a list of parents. e.g. AdminConfig.parent('JDBCProvider') gives us this exact list: 'Cell\nDeployment\nNode\nServer\nServerCluster' and even though Server comes before ServerCluster , running AdminConfig.parent('Server') reveals it's parents as: 'Node\nServerCluster'. Although some elements can have no parents - e.g. Cell - Some elements produce an error when running the parent function - e.g. Deployment.
Due to the apparent lack of a reciprocal AdminConfig.children() function, It appears as though obtaining a full hierachical tree of parents/children lies in calling this function on each of the elements returned from the AdminConfig.parent(<>) call and combining the results. That being said, a trial and error approach is mostly fruitful due to the sometimes obvious ordering.