I'm trying to parse presentation files from XBRL taxonomy.
This is an extract from file where I have trouble:
<presentationLink xlink:type="extended" xlink:role="http://www.infocamere.it/itnn/fr/itcc/role/NotaIntegrativaAttivo">
<presentationArc xlink:type="arc" xlink:arcrole="http://www.xbrl.org/2003/arcrole/parent-child" xlink:from="itcc-ci_AttivitaOperazioniLocazioneFinanziariaLocatario" xlink:to="itcc-ci_ContrattiCorsoOperazioniLocazioneFinanziariaLocatario" order="1" priority="0" use="optional"/>
<presentationArc xlink:type="arc" xlink:arcrole="http://www.xbrl.org/2003/arcrole/parent-child" xlink:from="itcc-ci_ContrattiCorsoOperazioniLocazioneFinanziariaLocatario" xlink:to="itcc-ci_BeniLeasingFinanziario" order="1" preferredLabel="http://www.xbrl.org/2003/role/periodStartLabel" priority="0" use="optional"/>
<presentationArc xlink:type="arc" xlink:arcrole="http://www.xbrl.org/2003/arcrole/parent-child" xlink:from="itcc-ci_BeniLeasingFinanziario" xlink:to="itcc-ci_BeniLeasingFinanziarioRelativiFondiAmmortamento" order="1" preferredLabel="http://www.xbrl.org/2003/role/periodStartLabel" priority="0" use="optional"/>
</presentationLink>
<presentationLink xlink:type="extended" xlink:role="http://www.infocamere.it/itnn/fr/itcc/role/NotaIntegrativaAttivo">
<presentationArc xlink:type="arc" xlink:arcrole="http://www.xbrl.org/2003/arcrole/parent-child" xlink:from="itcc-ci_ContrattiCorsoOperazioniLocazioneFinanziariaLocatario" xlink:to="itcc-ci_BeniLeasingFinanziario" order="2" preferredLabel="http://www.xbrl.org/2003/role/periodEndLabel" priority="0" use="optional"/>
<presentationArc xlink:type="arc" xlink:arcrole="http://www.xbrl.org/2003/arcrole/parent-child" xlink:from="itcc-ci_BeniLeasingFinanziario" xlink:to="itcc-ci_BeniLeasingFinanziarioRelativiFondiAmmortamento" order="1" preferredLabel="http://www.xbrl.org/2003/role/periodEndLabel" priority="0" use="optional"/>
</presentationLink>
The result should be
itcc-ci_AttivitaOperazioniLocazioneFinanziariaLocatario
itcc-ci_ContrattiCorsoOperazioniLocazioneFinanziariaLocatario
itcc-ci_BeniLeasingFinanziario (periodStartLabel, order=1)
itcc-ci_BeniLeasingFinanziarioRelativiFondiAmmortamento (periodStartLabel, order=1)
itcc-ci_BeniLeasingFinanziario (periodEndLabel, order=2)
itcc-ci_BeniLeasingFinanziarioRelativiFondiAmmortamento (periodEndLabel, order=1)
Is this the valid way to implements this hierarchy using presentationLink?
I have trouble identify parent node for 'itcc-ci_BeniLeasingFinanziarioRelativiFondiAmmortamento'.
Should I resolve parent for 'itcc-ci_BeniLeasingFinanziarioRelativiFondiAmmortamento' using presentationLinks as different containters and after merge presentationLinks to build the complete or I have only to scan every presentationArc and refer to last parent found?
I have read a lot of docs and code but I still have a doubts about how to solve this problem.
Thanks in advance to all for the answer.
I hope I was clear,English in not my native language.
You'll need to read the specifications. Neither of your suggestions are likely to result in the correct answer.
You need to work out the Network of Relationships for this relationship type and role. A very high level summary:
group the arcs into 'base sets' and find the one for this network
find the equivalent relationships
remove any prohibited or overridden relationships
You might get away without 2 & 3 if there aren't any. What you're left with is a bunch of relationships that describe this network which will allow you to build the tree.
If you have no idea what I'm talking about, then I'd strongly suggest using a 3rd party XBRL library. The specs aren't written in the most straightforward manner, and the fact English isn't your native language won't make this easier.
Related
I'm a bit confused over the difference between docstrings and comments in python.
In my class my teacher introduced something known as a 'design recipe', a set of steps that will supposedly help us students plot and organize our coding better in Python. From what I understand, the below is an example of the steps we follow - this so call design recipe (the stuff in the quotations):
def term_work_mark(a0_mark, a1_mark, a2_mark, ex_mark, midterm_mark):
''' (float, float, float, float, float) -> float
Takes your marks on a0_mark, a1_mark, a2_mark, ex_mark and midterm_mark,
calculates their respective weight contributions and sums these
contributions to deliver your overall term mark out of a maximum of 55 (This
is because the exam mark is not taken account of in this function)
>>>term_work_mark(5, 5, 5, 5, 5)
11.8
>>>term_work_mark(0, 0, 0, 0, 0)
0.0
'''
a0_component = contribution(a0_mark, a0_max_mark, a0_weight)
a1_component = contribution(a1_mark, a1_max_mark, a1_weight)
a2_component = contribution(a2_mark, a2_max_mark, a2_weight)
ex_component = contribution(ex_mark, exercises_max_mark,exercises_weight)
mid_component = contribution(midterm_mark, midterm_max_mark, midterm_weight)
return (a0_component + a1_component + a2_component + ex_component +
mid_component)
As far as I understand this is basically a docstring, and in our version of a docstring it must include three things: a description, examples of what your function should do if you enter it in the python shell, and a 'type contract', a section that shows you what types you enter and what types the function will return.
Now this is all good and done, but our assignments require us to also have comments which explain the nature of our functions, using the token '#' symbol.
So, my question is, haven't I already explained what my function will do in the description section of the docstring? What's the point of adding comments if I'll essentially be telling the reader the exact same thing?
It appears your teacher is a fan of How to Design Programs ;)
I'd tackle this as writing for two different audiences who won't always overlap.
First there are the docstrings; these are for people who are going to be using your code without needing or wanting to know how it works. Docstrings can be turned into actual documentation. Consider the official Python documentation - What's available in each library and how to use it, no implementation details (Unless they directly relate to use)
Secondly there are in-code comments; these are to explain what is going on to people (generally you!) who want to extend the code. These will not normally be turned into documentation as they are really about the code itself rather than usage. Now there are about as many opinions on what makes for good comments (or lack thereof) as there are programmers. My personal rules of thumb for adding comments are to explain:
Parts of the code that are necessarily complex. (Optimisation comes to mind)
Workarounds for code you don't have control over, that may otherwise appear illogical
I'll admit to TODOs as well, though I try to keep that to a minimum
Where I've made a choice of a simpler algorithm where a better performing (but more complex) option can go if performance in that section later becomes critical
Since you're coding in an academic setting, and it sounds like your lecturer is going for verbose, I'd say just roll with it. Use code comments to explain how you are doing what you say you are doing in the design recipe.
I believe that it's worth to mention what PEP8 says, I mean, the pure concept.
Docstrings
Conventions for writing good documentation strings (a.k.a. "docstrings") are immortalized in PEP 257.
Write docstrings for all public modules, functions, classes, and methods. Docstrings are not necessary for non-public methods, but you should have a comment that describes what the method does. This comment should appear after the def line.
PEP 257 describes good docstring conventions. Note that most importantly, the """ that ends a multiline docstring should be on a line by itself, e.g.:
"""Return a foobang
Optional plotz says to frobnicate the bizbaz first.
"""
For one liner docstrings, please keep the closing """ on the same line.
Comments
Block comments
Generally apply to some (or all) code that follows them, and are indented to the same level as that code. Each line of a block comment starts with a # and a single space (unless it is indented text inside the comment).
Paragraphs inside a block comment are separated by a line containing a single #.
Inline Comments
Use inline comments sparingly.
An inline comment is a comment on the same line as a statement. Inline comments should be separated by at least two spaces from the statement. They should start with a # and a single space.
Inline comments are unnecessary and in fact distracting if they state the obvious.
Don't do this:
x = x + 1 # Increment x
But sometimes, this is useful:
x = x + 1 # Compensate for border
Reference
https://www.python.org/dev/peps/pep-0008/#documentation-strings
https://www.python.org/dev/peps/pep-0008/#inline-comments
https://www.python.org/dev/peps/pep-0008/#block-comments
https://www.python.org/dev/peps/pep-0257/
First of all, for formatting your posts you can use the help options above the text area you type your post.
And about comments and doc strings, the doc string is there to explain the overall use and basic information of the methods. On the other hand comments are meant to give specific information on blocks or lines, #TODO is used to remind you what you want to do in future, definition of variables and so on. By the way, in IDLE the doc string is shown as a tool tip when you hover over the method's name.
Quoting from this page http://www.pythonforbeginners.com/basics/python-docstrings/
Python documentation strings (or docstrings) provide a convenient way
of associating documentation with Python modules, functions, classes,
and methods.
An object's docsting is defined by including a string constant as the
first statement in the object's definition.
It's specified in source code that is used, like a comment, to
document a specific segment of code.
Unlike conventional source code comments the docstring should describe
what the function does, not how.
All functions should have a docstring
This allows the program to inspect these comments at run time, for
instance as an interactive help system, or as metadata.
Docstrings can be accessed by the __doc__ attribute on objects.
Docstrings can be accessed through a program (__doc__) where as inline comments cannot be accessed.
Interactive help systems like in bpython and IPython can use docstrings to display the docsting during the development. So that you dont have to visit the program everytime.
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 am creating an ontology based on OWL/RDF/RDFS. My first ontology schema has namespaces as :
#prefix abc: https://example.com/a#
I want to change the namespace the next version of the ontology as
#prefix def: https://example-new.com/b#
But I dont want the previous users of the ontology to be affected at all. I was thinking if there is a way to define equivalent namespaces, and classify that the first name space will be deprecated. I am not sure if there is any provision in the OWL/RDF or even Dublin-core to so do.
Any help is appreciated. Thanks.
You can't do this at the namespace level but you can declare all old classes and properties as equivalent to the new ones; you'd keep the old IRIs in the equivalent axioms and declaration axioms only. Then any third part that uses a reasoner would be able to run queries just as before; parties not using a reasoner would have to rewrite their queries following equivalent axioms (something that they might already be doing for other similar use cases).
Let's say you need to funnel random, related data given to you into more succinct categories.
Example - You're given the following data. NOTE - There could be any number of other related, columnar data:
Customer Product Category
========== ========= =================================
Customer A Product A Cat 1
CustomerA Product B Category 1
Cust-A Product C Totally Lame & Unrelated Grouping
Task - Consolidate and normalize the above into clean, pre-defined groupings:
CustomerA
Category1
ProductA
ProductB
ProductC
Please don't worry about how the finished data will be persisted. But rather focus on how you'll persist and manage the rules for grouping.
Only one assumption: You can't use a database to persist your grouping rules. So when we say "normalize", we're not speaking in terms of relational database normalization rules. But rather we're wanting to remove inconsistencies from data inputs (as seen above) to bring the random data into a consistent state.
So what are the available options? Remain technology agnostic:
XML?
Config files?
Settings file (compiled or not)?
Ini File?
Code?
etc.
List pros & cons for each answer. And though this is indeed an excersize, it's a real-world problem. So assume your client/employer has tasked you with this.
This seems like a data cleansing exercise, perfection is pretty impossible. Issues:
1). Can you specify up front the categories, or must you deduce from the data?
2). What rules can we use to accept equivalence?
"Cat 1" is the same as "Category 1" ? and "Category one" ?
is
"Cat 1." als "Cat 1"? what about "Cat 1?" ? and "Cat 12" ?
Just getting a good set of rules in a challenge.
2). How would you capture those rules? Code or config? If config how would you express it? Do you end up just writing a new specilaised programming language?
This seems like a data cleansing exercise, perfection is pretty impossible. Issues:
1). Can you specify up front the categories, or must you deduce from the data?
2). What rules can we use to accept equivalence?
"Cat 1" is the same as "Category 1" ? and "Category one" ?
is
"Cat 1." als "Cat 1"? what about "Cat 1?" ? and "Cat 12" ?
Just getting a good set of rules in a challenge.
3). How would you capture those rules? Code or config? If config how would you express it? Do you end up just writing a new specilaised programming language?
A dictionary mapping for each value. 'Cat1' => 'Category1', 'Category 2' => 'Category2'. This is easy to store, and has no unintended consequences. The disadvantage is that creating all those mappings by hand is actual work.
A series of regular expressions. That way, you're able to capture nearly all rules using relatively little work. The disadvantage is that regular expressions 'misfire' relatively easily, and the order of evaluation matters (i.e. when values match more than one 'rule'.
As for how to persist them? I can't think of a more uninteresting question. You just use whatever's easiest in your preferred programming language.
I'm looking for a listing of all MySQL data types and the available settings for each option for each data type.
After a bit of googling I couldn't find anything quite like that.
here you can find a quick summary of mysql data types, with range, attributes and default value
For completeness' sake, don't forget the MySQL documentation.
Although the list is broken across multiple pages, often with a lot of commentary in between, it's a useful resource when you need to check some aspect of a particular type. There are also overviews of the basic types, but again, there's a lot of cruft mixed in with it.
if anyone ever needs them as a json array:
"[\"TINYINT[(M)]\", \"SMALLINT[(M)]\", \"MEDIUMINT[(M)]\", \"INT[(M)]\", \"BIGINT[(M)]\", \"FLOAT(p)\", \"FLOAT[(M,D)]\", \"DOUBLE[(M,D)]\", \"DECIMAL[(M,[D])]\", \"BIT[(M)]\", \"CHAR[(M)]\", \"VARCHAR(M)\", \"TINYTEXT\", \"TEXT\", \"MEDIUMTEXT\", \"LONGTEXT\", \"BINARY[(M)]\", \"VARBINARY(M)\", \"TINYBLOB\", \"BLOB\", \"MEDIUMBLOB\", \"LONGBLOB\", \"ENUM(\\\"A1\\\",\\\"A2\\\",...)\", \"SET(\\\"A1\\\",\\\"A2\\\",...)\", \"DATE\", \"DATETIME\", \"TIME\", \"TIMESTAMP\", \"YEAR\"]"