How do I indicate the max size of a property on EA?
Is there a special field?
Maybe creating a data type with maxsize propertie?
Just use the tab right to "Notes": "Constraints"
My OCL isn't very good (IOW it might be incorrect). You can also use Invariant instead of OCL and use plain text.
Related
when several Language Servers are providing document symbols. They are both displayed in Outline. It seems that the "displayName" of the extension is used to separate the 2 outlines.
Is it possible to provide a specific name?
I would like to provide a shorter ones that the extension display name to improve readability of the outline.
The current outline view looks alike this, cropping names by default as it is too long:
it wasn't possible. But it might be implemented soon: https://github.com/Microsoft/vscode/issues/62839
I am reading up on Schema.org to be able to add the markup to a website I am working on. However, I'm already running into something I don't understand.
In the example for Product, it shows you should have a div whose itemprop is of type offers, but in the Product definition at http://schema.org/Product, I don't see offers as a property of Product at all.
If you look at http://schema.org/offers, it says offers is a property of Thing, but I don't see offers listed as a property of Thing at http://schema.org/Thing. What am I misunderstanding here?
Product does define the offers property. If you don’t see the offers property in the first table on that page (under the table heading "Properties from Product"), you are probably affected by a (known) bug. It typically works again when reloading the page later.
offers doesn’t have Thing as domain (but: AggregateOffer, CreativeWork, Event, MenuItem, Product, Service, Trip). If you are referring to the line "Thing > Property > offers", it doesn’t mean that the offers property is defined for/at Thing, it means that the offers property is a Thing. You can ignore that detail. What matters is the domain ("Used on these types") and the range ("Values expected to be one of these types") of a property.
It's perhaps worth highlighting the distinction between "types" and "properties". The vocabulary is a hierarchical taxonomy of the tangible and intangible things around us, which it calls types. In microdata, these use the itemtype attribute.
Properties describe the attributes of and relationships between the types, and in microdata use the itemprop attribute.
So, the type Product has the property offers (it's definitely there, you must be missing it1). A product can offer various things, one of which is the possibility of having some right to own or use it, which is described by the type Offer.
The property offers is indeed a property of Thing, but Thing is at the very top of the taxonomy, i.e. everything the ontology describes is a "thing", tangible or otherwise. So Thing is then broken down into more specific types of things:
Thing
- Intangible
-- Offer
-- Property
--- offers
So offers is a Thing like you and I are things — it's true, but we could be a lot more specific. In this case, offers is a property of the type Property, which in turn is a a more specific type of Intangible, which is a Thing.
1 Image of "offers" property under /Product:
I'm confused about the limitations on the ASN.1 SET type. In general, I realize that a SET type is basically the same as a SEQUENCE, except the order of the components doesn't matter.
The seminal book on ASN.1, "ASN.1 — Communication Between Heterogeneous Systems" by Olivier Dubuisson, has this to say about SETs:
If the component order of the SEQUENCE type does not matter, the key-
word SET is used for modeling such a non-ordered structure:
Description ::= SET {
surname IA5String,
first-name IA5String,
age INTEGER }
In this case, the application can provide the components to the
encoder in the best order for it.
What I immediately notice here is that in Dubuisson's example, the SET has two IA5String types in it. This seems to contradict what I've read here in this tutorial, which explicitly says that:
The type and value notations for SET are similar to SEQUENCE,
except that the type of each component must be distinct from all
others and the values can be in any order.
So how can a SET legally have two IA5String types? I'm inclined to trust Olivier Dubuisson's book over some random Internet tutorial, however, it doesn't make any sense that a SET type could have multiple components of the same type. The reason is that, in ASN.1, type identifiers aren't encoded, (at least for most common encodings like BER) so the decoder would have no way of knowing which component the IA5String applies to - is it surname or firstname? There's no way to tell if the ordering doesn't matter.
So did Olivier Dubuisson make a huge mistake here? (He also doesn't mention anywhere in his lengthy description of SET types anything about the fact that a SET can't have more than one of each type.)
The standard (X.680, 27.3) requires that the types of the components of a SET type all have different tags.
The "Description" type in the example violates this requirement if the enclosing ASN.1 module has IMPLICIT TAGS or EXPLICIT TAGS (because the types of the components surname and first-name have the same tag "universal 22"), but it is legal if the enclosing ASN.1 module has AUTOMATIC TAGS (because the types of those components now have different tags--"context-specific 0" and "context-specific 1", respectively--automatically assigned to them in replacement of the "universal 22" tags).
If there are two components with the same type in a SET, they can indeed not be distinguished. The example can still be correct provided it appears in a module with automatic tagging.
I would like to know if there is anyone who has implemented the subjectscheme maps of DITA1.2 in their work? If yes, can you please break-up the example to show:
how to do it?
when not to use it?
I am aware of the theory behind it, but I am yet to implement the same and I wanted to know if there are things I must keep in mind during the planning and implementation phase.
An example is here:
How to use DITA subjectSchemes?
The DITA 1.2 spec also has a good example (3.1.5.1.1).
What you can currently do with subject scheme maps is:
define a taxonomy
bind the taxonomy to a profiling or flagging attribute, so that it the attribute only takes a value that you have defined
filter or flag elements that have a defined value with a DITAVAL file.
Advantage 1: Since you have a taxonomy, filtering a parent value also filters its children, which is convenient.
Advantage 2: You can fully define and thus control the list of values, which prevents tag bloat.
Advantage 3: You can reuse the subject scheme map in many topic maps, in the usual modular DITA way, so you can apply the same taxonomies anywhere.
These appear to be the main uses for a subject scheme map at present.
The only disadvantages I have found is that I can think of other hypothetical uses for subject scheme maps such as faceted browsing, but I don't think any implementation exists. The DITA-OT doesn't have anything like that yet anyway.
In my application I need two combo boxes, the content of second one depends on the current selection of first combo. Should I use JFace ComboViewer for this? or shall I directly use combo?
If I use JFace ComboViewer what flexibility I'll get? or how JFace ComboViewer is better than Combo?
For more clarity, I have to use only strings for my combo.
Thanks in advance!!!
The primary difference - as far as I am concerned - is the use of a ILabelProvider for ComboViewer, whereas you have to calculate the entries yourself for Combo. Whether to use one or the other depends on the specific use-case...
Combo is just the widget, ComboViewer wraps that so you use a model other than just strings. You rarely want to create and interact with plain widgets directly.