I have a taxonomy entry point that refers to three linkbases, one of which is a presentation linkbase. When opening the entry point XSD, my XBRL tool discovers many more concepts than are present in the presentation linkbase, most of which are irrelevant for the report in question.
Is there a programmable way of deciding which concepts are to be reported, for instance by only reporting concepts which are present in a discovered presentation linkbase? Or does a human being always need to read some taxonomy-specific documentation and then select the concepts?
To give the example behind my question. I was referring to the entry point www.nltaxonomie.nl/10.0/report/bd/entrypoints/bd-rpt-ob-aangifte-2016.xsd. (The complete taxonomy is available at www.sbr-nl.nl/fileadmin/SBR/documenten/NT_2016/SBR_NT_10.0.zip.)
For instance, the XBRL editor of my choice displays concept BusinessProfitTitle coming from www.nltaxonomie.nl/10.0/report/bd/abstracts/bd-abstracts.xsd. BusinessProfitTitle is not included in the presentation linkbase www.nltaxonomie.nl/10.0/report/bd/linkroles/bd-aangifte-omzetbelasting-pre.xml, which is referred to by the entry point and which only contains concepts related to value-added tax. The entry point refers to two more definition linkbases, which seem to contain more concepts than are relevant. So I was wondering how to derive the concepts that must be reported for the entry point above, when you don’t speak Dutch and would like to derive the concepts programmatically.
There is nothing in the XBRL 2.1 specification that directly address your question.
There is something called "the formula linkbase" that might produce validation errors from content in the original instance document and the DTS. Within the "formula linkbase specification set" there are "Existence assertions" and some regulators are using the "Value assertions" for the purposes of detecting when a concept has been reported and the value reported is "valid".
This does depend somewhat on the filing system in question, but typically, the concepts covered by a presentation tree are the ones relevant to the entry point in question, and you can safely ignore all other concepts.
The schemas defining concepts are often shared by the entry points for multiple report types, so it's not uncommon to find concepts that are not covered by the presentation for a particular entry point.
Related
I understand XBRL presentation networks very well, and I also understand the mechanisms of prohibiting and overriding relationships, but the way to extend a presentation network with a new, custom concept eludes me.
A presentation network defines a hierarchy of locators, where each locator points to a concept. This makes it possible for the same concept to appear multiple times inside the same network (for example the Equity concept in the Changes of Equity statement, IFRS taxonomy).
The question is: How can an extension taxonomy attach a new arc to a particular locator in the base taxonomy? When an extension taxonomy defines a new arc, that new arc points to two new locators in the same extension taxonomy and will therefore not integrate with the network that is defined by the base taxonomy.
The locators are "proxies" to concepts, and a syntactic detail. From a logical perspective, a presentation network is a DAG of report elements (="concepts" in specese). When prohibiting and overriding, what matters in the resolution of the DTS is the concepts, not the locators.
In specese wording, two relationships are equivalent if their (non-exempt) attributes match, and the XML fragments on the from and to sides are identical. The XML fragments of the from and to sides, in a presentation network, are the concepts, not the locators.
An extension taxonomy will thus have its own locators, but pointing to the same concepts if it wants to reuse them.
I'm curious of thoughts on how one would want to apply schema to a list of completed projects, for example, a listing of projects that were completed by an architecture firm.
So let's say you have a list of projects that were completed, consisting of information such as the date, location, description, etc.
I don't know if it is necessarily considered a Creative Work, or a place. I'm considering using the general ItemList/Item properties but not sure if there is much value in it. So having said that, would anyone expect this to be beneficial or worth doing?
You tagged your question with seo and html, but those are not reasons to define an XML Schema (XSD). You mention "Creative Work", but that concept is also immaterial to XSDs and their benefits.
The Value of Defining an XSD
There is value in defining an XSD in so far as you, or the software you use, or the partners with whom you exchange data would benefit from the clear definition and automatic validation of structured documents.
If these reasons are not relevant to your work, you probably don't need to define an XSD.
As best I can tell, XBRL allows SEC filers to use the same concept for multiple facts so long as the context is different. I'm having a difficult time understanding how to include/exclude a fact for a given roleURI (a statement, for instance). I believe this ability is somehow related to context, but there doesn't seem to be an obvious link between the concepts asked for in the presentation document and the appropriate concept in the instance. To ask this a different way:
1) The company has several roleURIs (networks), perhaps one of which is "http://www.bigcompany.com/role/StatementOfIncome"
2) In the *_pre.xml document section related to this network, the company has asked that a "Revenues" concept be displayed.
3) The instance document has multiple "revenue" items, each with different contexts, and some with segments related to the company's sub-entities.
How do I determine that a revenue item with a certain context belongs on the StatementOfIncome roleURI, and another one should be excluded?
Thanks for any hints or resources...
As you note, the presentation linkbase is context-agnostic. From the exhibits themselves, there is no explicit way to know which numbers were actually printed on the Income Statement and which facts using the same element/concept are from other schedules.
The SEC uses programmatic means to determine what will be rendered where in its Pre-Viewer and Viewer; they explain some of that in their FAQs and Interpretations (see, for example, question B.3 at http://www.sec.gov/spotlight/xbrl/staff-interps.shtml). They look at key words and phrases.
The SEC makes the source code to their rendering engine available at http://www.sec.gov/spotlight/xbrl/viewers.shtml - you may be able to leverage it or find other hints of how they determine what to print and when.
XBRL was not designed to recreate the original presentation; later developments including Inline XBRL and the new Table Linkbase do more to preserve presentation placement.
I accepted the given answer as correct, but after several more days of banging my head on this issue, I can't quite yet see it. I keep thinking that facts somehow HAVE to "belong" to a network via their context. As best I can tell, facts with contexts having segments belong on networks with hypercube dimensions that match (somehow) the context segment "explicitMember" values. Facts with context without segments belong on networks either that have no hypercube dimensions or that relate to the company has a whole. But I can't make heads or tails of this. When I've gone through and looked at how XBRL gets made using software, facts and contexts are added to documents as networks are added. Somehow, there's a connection there. The SEC's software is helpful, but I haven't quite wrapped my head around what they did either.
I wish there were better resources on learning to parse XBRL. Most of what I've seen relates to creating it...
If ever I figure this out, I'll revisit this question with better details!
Are there any common terms for the difference between data validation you can do on, say, an object in and of itself, and validation that requires access to some sort of external resources?
For example, if I have a user record, I can check things like "Is username present?" "Is Username at least n characters long?" etc., without requiring any additional context. But as soon as I want to do something like "Is username available?" It requires checking against other records in my system.
I'm just wondering if there are any good terms for describing the difference in these types of scenarios? "Static analysis" vs. "run-time checking" sort of fits, but it's clearly not correct.
I don't really know of any widely accepted terms for these different kinds of validation. Wikipedia provides you some guidance.
What's important is that you define/use a set of terms that everyone in your team agrees with and uses. I believe that the terms you're proposing (static vs runtime) are not good because all these rules are exercised at runtime anyway. I would propose something like intrinsic vs extrinsic or internal vs external validation.
I use UML Sequence Diagrams all the time, and am familiar with the UML2 notation.
But I only ever use them to capture the essence of what I intend to do. In other words the diagram always exists at a level of abstraction above the actual code. Every time I use them to try and describe exactly what I intend to do I end up using so much horizontal space and so many alt/loop frames that its not worth the effort.
So it may be possible in theory but has anyone every really used the diagram in this level of detail? If so can you provide an example please?
I have the same problem but when I realize that I am going low-level I re-read this:
You should use sequence diagrams
when you want to look at the behavior
of several objects within a single use
case. Sequence diagrams are good at
showing collaborations among the
objects; they are not so good at
precise definition of the behavior.
If you want to look at the behavior of
a single object across many use cases,
use a state diagram. If you want
to look at behavior across many use
cases or many threads, consider an
activity diagram.
If you want to explore multiple
alternative interactions quickly, you
may be better off with CRC cards,
as that avoids a lot of drawing and
erasing. It’s often handy to have a
CRC card session to explore design
alternatives and then use sequence
diagrams to capture any interactions
that you want to refer to later.
[excerpt from Martin Fowler's UML Distilled book]
It's all relative. The law of diminishing returns always applies when making a diagram. I think it's good to show the interaction between objects (objectA initializes objectB and calls method foo on it). But it's not practical to show the internals of a function. In that regard, a sequence diagram is not practical to capture the logic at the same depth as code. I would argue for intricate logic, you'd want to use a flowchart.
I think there are two issues to consider.
Be concrete
Sequence diagrams are at their best when they are used to convey to a single concrete scenario (of a use case for example).
When you use them to depict more than one scenario, usually to show what happens in every possible path through a use case, they get complicated very quickly.
Since source code is just like a use case in this regard (i.e. a general description instead of a specific one), sequence diagrams aren't a good fit. Imagine expanding x levels of the call graph of some method and showing all that information on a single diagram, including all if & loop conditions..
That's why 'capturing the essence' as you put it, is so important.
Ideally a sequence diagram fits on a single A4/Letter page, anything larger makes the diagram unwieldy. Perhaps as a rule of thumb, limit the number of objects to 6-10 and the number of calls to 10-25.
Focus on communication
Sequence diagrams are meant to highlight communication, not internal processing.
They're very expressive when it comes to specifying the communication that happens (involved parties, asynchronous, synchronous, immediate, delayed, signal, call, etc.) but not when it comes to internal processing (only actions really)
Also, although you can use variables it's far from perfect. The objects at the top are, well, objects. You could consider them as variables (i.e. use their names as variables) but it just isn't very convenient.
For example, try depicting the traversal of a linked list where you need to keep tabs on an element and its predecessor with a sequence diagram. You could use two 'variable' objects called 'current' and 'previous' and add the necessary actions to make current=current.next and previous=current but the result is just awkward.
Personally I have used sequence diagrams only as a description of general interaction between different objects, i.e. as a quick "temporal interaction sketch". When I tried to get more in depth, all quickly started to be confused...
I've found that the best compromise is a "simplified" sequence diagram followed by a clear but in depth description of the logic underneath.
The answer is no - it does capture it better then your source code!
At least in some aspects. Let me elaborate.
You - like the majority of the programmers, including me - think in source code lines. But the software end product - let's call it the System - is much more than that. It only exists in the mind of your team members. In better cases it also exists on paper or in other documented forms.
There are plenty of standard 'views' to describe the System. Like UML Class diagrams, UML activity diagrams etc. Each diagram shows the System from another point of view. You have static views, dynamic views, but in an architectural/software document you don't have to stop there. You can present nonstandard views in your own words, e.g. deployment view, performance view, usability view, company-values view, boss's favourite things view etc.
Each view captures and documents certain properties of the System.
It's very important to realize that the source code is just one view. The most important though because it's needed to generate a computer program. But it doesn't contain every piece of information of your System, nor explicitly nor implicitly. (E.g. the shared data between program modules, what are only connected via offline user activity. No trace in the source). It's just a static view which helps very little to understand your processes, the runtime dynamics of your living-breathing program.
A classic example of the Observer pattern. Especially if it used heavily, you'll hardly understand the System mechanis from the source code. That's why you use Sequence diagrams in that case. It captures the 'dynamic logic' of your system a lot better than your source code.
But if you meant some kind of business logic in great detail, you are better off with plain text/source code/pseudocode etc. You don't have to use UML diagrams just because they are the standard. You can use usecase modeling without drawing usecase diagrams. Always choose the view what's the best for you and for your purpose.
U.M.L. diagrams are guidelines, not strictly rules.
You don't have to make them exactly & detailed as the source code, but, you may try it, if you want it.
Sometimes, its possible to do it, sometimes, its not possible, because of the detail or complexity of systems, or don't have the time or details to do it.
Cheers.
P.D.
Any cheese-burguer or tuna-fish-burguer for the cat ?