I've read through the doc and spec of JSON-LD and JSON-LD-API (and might as well have missed something).
I found that the local context of an object node may be composed by defining "#context: [.., .., ...]" as an array of multiple context definitions (some of which may be inlined, others may be external references). I also found that referencing an "external context" assumes the corresponding IRI reference resolves to a JSON-LD document with an expected #context definition in its root object node, which is to be used in place of the original reference to the "external context".
My question is: Is it valid (or reasonable, or implied), that the referenced #context in the remote JSON-LD document may also be composite (just like an ordinary local #context), or is a referenced external context restricted to being a definite context entity (i.e. either a local XOR external definition, i.e. NOT an array of many context definitions)?
(This question is probably directed towards the authors of the JSON-LD standard).
A remote context is not restricted in any way which means that it can contain references to other contexts.
Related
I am learning qemu and qom recently. I am perplexed when I meet the conception of ObjectClass and Object. I already understand that ObjectClass stands for class while Object means instance of class. However, what I want to know is What kind of information should store in ObjectClass and what's going on in Object.
As far as I am concerned, like C++ or Java, Object just the same as what's define in Class and be used in real logic. In this case, Class seems like a template which produce Object the real be used.
In qemu, everything seems different. We define these two in two struct, and they have different properties, which leads to separation of Class and Object. Does it means I can use one ObjectClass to produce many Object that differ with each other? And secondly, why should I do this? Are there any advantages of this pattern? In detail, what's the role ObjectClass and Object plays in qemu respectively? And what about their relationship? If I want to design a new device, What should I do in initialization of MyObjectClass and MyObject?
What's more, I notice that qemu will initialize every ObjectClass by TypeImpl, which is initialized by TypeInfo defined by developer.
TypeInfo => ModuleEntry => TypeImpl => ObjectClass => Object
Of course they do different things. TypeInfo converts to ModuleEntry before main function is executed(__attribute__((constructor))), which contains initial functions of ObjectClass and Object. Why we need this mechanism? On the other words, what if we just create ObjectClass instead of create TypeImpl and create ObjectClass after that? Any advantages?
This is part of QEMU's object model (QOM), which is documented in the developer section of the documentation. You should read that, and also look through include/qom/object.h for more details of the object model.
In QOM, for any class there is one class struct -- for the base Object type the class struct is ObjectClass. There are then multiple objects created at runtime, each of which is a struct Object. This applies also for subtypes of Object, like DeviceState, whose class struct is DeviceClass. The class struct holds fields which are common to every instance of that object type, notably including the function pointers which are the equivalent of methods. The object struct holds all the fields which are per-instance. Because each Object contains a pointer to the corresponding ObjectClass, you can always get from a pointer to an instance of an object to its class information.
Because we're implementing an object-oriented model in C, we have to have everything be explicit -- in C++ and Java, because the object model is part of the language the compiler can sort out under the hood a lot of the things QOM has to manage manually with class structs and object structs and so on.
More generally, if your aim is "write a new device" I would recommend that you do not spend any time looking into the internals of the QOM implementation. Instead you should look at how other devices similar to yours are implemented and at what the patterns of code are that they use to declare and use a new device type.
the full sentence taken from the EJB3.2 specifications:
When interacting with a reference to the no-interface view, the client
must not make any assumptions regarding the internal implementation of
the reference, such as any instance-specific state that may be
present in the reference
I'm actually trying to understand what that actually mean and I was wondering if someone could kindly provide some examples.
EDIT:
The Above sentence is take from Section 3.4.4 Session Bean’s No-Interface View, maybe this info is helpful
When generating a no-interface view proxy, the EJB container must create a subclass of the EJB class and override all public methods to provide proxying behavior (like security, transactions).
You can get a reference to the bean with (eg. for passing it to another ejb):
NoInterfaceBean bean = ejbContext.getBusinessObject(NoInterfaceBean.class);
This returns a reference with a class-type that is the same as the bean class itself (normally if the EJB has a business interface it would return the interface class), but it is not a reference to an instance of NoInterfaceBean (but to that proxy class with the same name). Think of it as a reference to a pimped version of your bean, about which you
must not make any assumptions regarding the internal implementation
It's basically the same with "normal" EJB's. You know that there is some magic around your bean instance, but since you get the interface as class-type it's already clear that every class implementing the interface can have a different internal implementation.
So the specification emphasizes this difference at that point. Even if it looks like a reference to your concrete class it is none (as they say in the next paragraph of the specification JSR-000345 Enterprise JavaBeansTM 3.2 Final Release:
Although the reference object is type-compatible with the
corresponding bean class type, there is no prescribed relationship
between the internal implementation of the reference and the
implementation of the bean instance.
When working with datastore entities in App Engine, people have noticed odd behavior after a put operation is performed on an entity if you choose to hold on to a reference of that entity.
For example, see this issue where repeated String properties mutated to _BaseValue after a put was performed.
In the ensuing discussion, in reference to a repeated String property, Guido van Rossum writes:
"I see. We should probably document that you're not supposed to hang
on to the list of items for too long; there are various forms of
undefined behavior around that."
I get the sense from this thread that it's not a good idea to maintain reference to an entity for too long after a put, as unexpected behavior might arise.
However, when I look at the GAE source code for the Model.get_or_insert() method, I see the following code (docstring removed):
#classmethod
def get_or_insert(cls, key_name, **kwds):
def txn():
entity = cls.get_by_key_name(key_name, parent=kwds.get('parent'))
if entity is None:
entity = cls(key_name=key_name, **kwds)
entity.put()
return entity
return run_in_transaction(txn)
Notice how a put operation is performed, and the entity is returned post-put. Just above, we saw an example of when this is not recommended.
Can anyone clarify when and when it is not ok to maintain a reference to an entity, post put? Guido seemed to hint that there are various scenarios when this could be a bad idea. Just curious if anyone has seen documentation on this (I cannot find any).
Thanks!
The problem described in the issue is not regarding entities, but rather lists obtained from its properties. You can hold a copy of entity as long as you like. It's just an object.
The issue is caused by some "magical" functionality provided by ndb. Let's take a look at the model definition
from google.appengine.ext.ndb import model
class MyModel(model.Model):
items = model.StringProperty(repeated=True)
What can we say about items property?
It looks like a class attribute, but metaclass logic of model.Model transforms it into an instance attribute.
What type are these instance attributes?
They can be accessed like a list of strings, but they are more complex objects having the logic required for storing and retrieving the data from datastore, validating etc.
This "magic" works well in most cases, but sometimes it doesn't. One of the problematic cases is when you get the reference to items from the instance and try to use it after put was called. Another case, mentioned by Guido, was to pass external list to initialize items property and then try to modify this property by manipulating the external list.
The thing to remember: Model properties in ndb try to behave like their basic types, but they are more complex objects. You can read more about their internals in Writing property subclasses
What is the correct mime-type type of esoteric languages?
I've googled everywhere, I even tried to ask Chuck Norris, but I didn't find the answer anywhere.
I have tried these for Brainfuck:
application/brainfuck
application/x-brainfuck
application/x+brainfuck
x-esoteric/x-brainfuck
chuck-norris-choice/brainfuck
x-you-lost-the-game/x-fuck-your-brain
42/++++++++[>++++[>++>+++>+++>+<<<<-]>+>+>->>+[<]<-]>>.>---.+++++++..+++.>>.<-.<.+++.------.--------.>>+.>++.
But none of them seemed to work.
A far as I'm aware, there is no 'official' media type for brainfuck (Official types listed here). You are of course free to make up your own without officially registering the type, but you should take a few things into consideration before choosing what name to use. All the information you need is in RFC2046. I'll discuss the relevant parts below.
Top Level Media Type
As far as I can see, the two options you might choose from are text and application:
text
According to Section 3:
The subtype "plain" in particular indicates plain text containing no formatting commands or directives of any sort. Plain text is intended to be displayed "as-is". No special software is required to get the full meaning of the text, aside from support for the indicated character set.
If you intend for the data to be displayed rather than interpreted by an application, I would use this.
Section 4.1.4 mentions the following about unrecognised subtypes:
Unrecognized subtypes of "text" should be treated as subtype "plain" as long as the MIME implementation knows how to handle the charset.
Setting your top level media type to text will ensure that compliant applications that do not recognise the full type will still render the data as text.
application
If you intend your data to be interpreted or processed further, you should use the application top-level media type. As in the argument above, if you label your data as application, any programs that receive it are more likely to behave in a sensible fashion.
Section 4.5.3 deals with unrecognised application types:
It is expected that many other subtypes of "application" will be defined in the future. MIME implementations must at a minimum treat any unrecognized subtypes as being equivalent to "application/octet-stream".
Reading the appropriate section (Section 4.5.1) we find out how applications are supposed to handle octet streams:
The recommended action for an implementation that receives an "application/octet-stream" entity is to simply offer to put the data in a file, with any Content-Transfer-Encoding undone, or perhaps to use it as input to a user-specified process.
If this seems like the most logical way to handle your data when it is unrecognised, then application is for you.
Sub-type
Choosing the subtype is much easier. Section 6 covers experimental media types:
A media type value beginning with the characters "X-" is a private value, to be used by consenting systems by mutual agreement. Any format without a rigorous and public definition must be named with an "X-" prefix, and publicly specified values shall never begin with "X-".
So your subtype should be X-brainfuck.
Summary
You have two options:
text/X-brainfuck
application/X-brainfuck
If you intend for applications to treat the data as plain text and display it, choose 1. If you intend the data to be interpreted or executed, choose 2. If you're unsure what you want to happen, choose 2, because the default expectation is that an application will prompt the user for what to do if it does not recognise the type.
I have no clue why you think application/... is an appropriate mime type for a text file.
One generally accepted MIME type for .bf is text/x-brainfuck. This is a language, not an executable.
Is it ok if a URN leads me to a 404?
A URN that leads to a 404 is valid? May it be used for describing XML files?
Yes, it’s okay. Actually, that’s the point of URNs: they are "location independent":
Uniform Resource Names (URNs) are resource identifiers with the specific requirements for enabling location independent identification of a resource, as well as longevity of reference.
(https://www.rfc-editor.org/rfc/rfc3406#section-1.0)
URNs identify. E.g. urn:isbn:0451450523 represents the book with the ISBN 0451450523. That’s it. No (canonical) web page etc. The corresponding specification of this isbn namespace would be https://www.rfc-editor.org/rfc/rfc3187.
(Of course you could use client-side resolvers, e.g. browser add-ons, that "do something" when encountering URNs.)
may it be used for describing XML files?
Note that you can’t just start minting URN namespaces. You need to register them. You can find all registered URN namespaces there: http://www.iana.org/assignments/urn-namespaces
Now, if there is an appropriate URN namespace for your use case you could use such URNs, if you follow the specification of that particular namespace.
(For "for use within internal or limited experimental contexts" you could mint URN namespaces starting with X- without registration.)