I am not able to figure out from where I can get the URL for the 'scheme' attribute of xbrli:identifier tag in the 'entity' portion of a context definition in an XBRL document. I am not able to find it in the taxonomies or link bases. I have searched the net for hours.
The taxonomy I'm following is IFRS based.
Thanks in advance. :)
Section 4.7.3.1 of the XBRL Specification states:
An element specifies a #scheme for identifying business
entities. The required #scheme attribute contains the namespace URI of
the identification #scheme, providing a framework for referencing
naming authorities. The element content MUST be a token that is a
valid identifier within the namespace referenced by the #scheme
attribute. XBRL International is not a naming authority for business
entities. XBRL makes no assumption about the ability of an application
to resolve an identifier that may appear as element content in any
particular scheme.
Therefore, the URI used as the value for the scheme attribute is context specific. In other words, it is not defined by XBRL, but by the context of the usage implied by the taxonomy.
The element a required element in a context. It identifies the entity that is reporting the facts. It contains an identifier element and may include a segment description. The value of the scheme attribute, therefore, means something to the reporting entity rather than to the XBRL specification itself.
Related
We are implementing SCIM Resource Provider for Users, Groups and a couple of custom resources.
SCIM Core Schema RFC 7643 defines User resource so, that only userName and core attributes (id, schemas) are required. Plus it defines optional attributes like name, profileUrl, etc.
Some optional attributes do not make sense in our context (e.g. ims) or are not supported or very expensive to be supported.
From the other hand, other optional attributes like name should be "required" and should be returned "always".
What is the recommended way to express this, so that the clients would know what attributes should be provided?
As much I understand rfc, we should provide the adjusted, tweaked version of core User schema on /Schemas endpoint. Is it correct way?
Would it make our Provider "none SCIM compliant"?
Discussion has been started on scim mailing list. Here is the answer from Phil Hunt, one of rfc authors:
This happens a lot particularly when adapting SCIM protocol on top of applications (e.g. payroll, HCM, CRM, etc). Each app has data they care about that is a sub-set of what is seen in IDM systems. The point of 7643 is really to define standard attribute names, types, syntax, and handling that developers can count on.
IMO, you do not have to implement the schema exactly as published in 7643. It is quite common practice to omit attributes (e.g. such as an app that doesn’t care about ims). Note that renaming standard attributes or changing their formats will produce interop concerns.
Use the extension mechanism to define your own app specific attributes (see section 3.3 of 7643 and 4.3 for the EnterpriseUser example).
You are free to omit unused attributes from your schema. You document what your server actually supports in the /Schemas endpoint.
The full discussion can be found on https://www.ietf.org/mail-archive/web/scim/current/msg02851.html
I am trying to understand more on the physical and logical structure of an XML document. From the specification at W3C describing the physical structures:
An XML document may consist of one or many storage units. These are
called entities;...
So my question is:
What exactly is a storage unit referring in this context?
Is it used from the perspective of an XML processor and how it would store and manipulate the XML document in memory or is it referring to a persistent storage used to store the document?
An entity in XML and SGML represents a character stream. It can be an external entity, where the character content is accessed from another file or network (HTTP) stream, or an internal entity, which is part of the literal content of the document in which it's declared and referenced. An internal entity can be declared like this
<!ENTITY e "replacement text for e">
and then used as the &e; entity reference in content like this
<p> some text ... &e; ... other text </p>
such that an XML or SGML processor will replace &e; with replacement text for e. The concept of an entity is also used for other purposes.
As to the second question, the entity concept is related to "storage" of character data in external files or network streams; it doesn't refer to internal memory representations of a markup processor.
I'm reading the ECMAScript 5.1 Specification but I'm stuck with the following sentence:
Specification type values are specification artefacts that do not necessarily correspond to any specific entity within an ECMAScript implementation.
If they do not necessarily correspond to any specific entity, what do they correspond? I mean a specification type value belongs to the set of specification type values (obviously), so what does that sentence want to say?
The ECMAScript spec describes how the language should behave from the standpoint of a script executing within a conforming environment. It does not describe how that environment should be implemented, just how the script running inside it should work given a set of inputs.
The first part of that sentence is important to the context here:
A specification type corresponds to meta-values that are used within algorithms to describe the semantics of ECMAScript language constructs and ECMAScript language types. The specification types are Reference, List, Completion, Property Descriptor, Property Identifier, Lexical Environment, and Environment Record.
So the "specification type" in the quote you posted:
Specification type values are specification artefacts that do not necessarily correspond to any specific entity within an ECMAScript implementation.
is one of those types, like "Reference" or "Property Identifier".
The point that this is trying to get across is that your implementation is free to implement these concepts however it pleases. There is no requirement that your implementation have some object that represents a "Reference" type, or some object that represents "Completion" or any of the others. As long as, from the standpoint of a script running on your implementation, things look correct, you are free to implement the language however you please.
As recently as 2002 the IETF was recommending in RFC 3406 that we should use x- prefixes for URN namespaces we didn't want to register, e.g. urn:x-acme:foobar. Now that the IETF has deprecated the x- prefix in RFC 6648, how are we supposed to construct URNs for namespaces we don't intend to register?
As an aside, I note that RFC 6648 specifically mentions URNs: "In almost all application protocols that make use of protocol parameters (including ... URNs ...), the name space is not limited or constrained in any way, so there is no need to assign a block of names for private use or experimental purposes." I find this an odd thing to say, as RFC 3406 claims, "The space of URN namespaces is managed. I.e., not all syntactically correct URN namespaces (per the URN syntax definition) are valid URN namespaces."
So what is best to use for custom but unregistered URN namespaces? Can I just drop the x- and use, for my example company Acme, a URN such as urn:acme:foobar?
RFC 6648 says:
Does not override existing specifications that legislate the use of "X-" for particular application protocols […]; this is a matter for the designers of those protocols.
So it’s still fine to use experimental NIDs as defined by RFC 3406.
And what RFC 6648 recommends for new protocols (and, I assume, updates of existing protocols) is essentially what is currently the case with URNs anyway (minus the experimental X- prefix):
there is a "potentially unlimited value-space" for NIDs
there are "clear registration procedures" defined (I have no idea what they understand under "simple")
So in case experimental X- NIDs should get deprecated in an updated RFC, I wouldn’t expect an alternative to having to register NIDs.
If you don’t want to register NIDs (even not an Informal NID), you might want to use a different URI scheme. tag comes to mind (tag:example.com,2013:foobar).
On
this page
it mentions JSON fields and properties
specify a particular field or property to examine
What is the difference between a JSON field and property?
Nothing.
When talking about JSON (as opposed to C# or C++), both terms mean the same thing.
He mentions both terms to clarify for people who are only familiar with one of them.