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.
Related
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:
In my (chemistry related) project, I'd like to use the words Elementand Sequence for data structures. Will there be a conflict with the same names that are already used in Swift, should I rename them to MyElement and MySequence to be safe?
UPDATE:
I'm editing the question to hopefully make it more clear as was requested. The following quote is from the Generics section of Apple's Swift documentation:
Element defines a placeholder name for “some type Element” to be
provided later on. This future type can be referred to as “Element”
anywhere within the structure’s definition. In this case, Element is
used as a placeholder in three places
So, my question was if I can use the word Element for a structure without conflicting. The same for Sequence which I have seen used as well in sample code - although I cannot find it anymore. The accepted answer below explains this.
Those are not reserved words in Swift. The identifier Element is used as an associated type inside some generic types in the standard library, but you can also use it for your own type if you want, although it might become confusing. The identifier Sequence is not currently used by the standard library.
1) Assume that when media type name is set to "X/xml", the software agent SA is capable of identifying Hypermedia controls contained in representation format RF
a) If SA receives the following HTTP reply ( which contains RF ), then "text" part of the media type name text/xml informs SA that it should process RF as plain XML ( thus it shouldn't try to identify Hypermedia controls )?
HTTP/1.1 200 OK
...
Content-Type: text/xml
...
<order xmlns=″...″>
...
<link rel=...″
href=...″/>
</order>
b) But if instead SA receives the following HTTP reply, then "X" part in media type name X/xml which informs SA that while processing RF it should also identify Hypermedia controls?
HTTP/1.1 200 OK
...
Content-Type: X/xml
...
<order xmlns=″...″>
...
<link rel=...″
href=...″/>
</order>
2) If my understanding in 1) is correct, then I assume all values preceding "xml" ( say "X/vnd.Y" in media type name X/vnd.Y+xml ) are used to inform software agent which processing model it should use with xml document?
EDIT:
I apologize in advance for being so verbose
1)
To clarify, XML has no hypermedia controls. I assume you meant a
hypermedia-capable XML format such as Atom (application/atom+xml).
I know XML is just a markup language and thus has no Hypermedia controls. But my understanding is that if my custom media type MyMedia/xml identifies BeMyLink element ( defined within XML Schema namespace MySchemaNamespace ) as Hypermedia control, then when processing the following XML document in accordance with MyMedia/xml ( thus when Content-Type header is set to MyMedia/xml ), the BeMyLink element is considered a Hypermedia control:
<MyCreation xmlns="MySchemaNamespace">
<BeMyLink rel="..."
href="..."/>
</MyCreation >
?
2)
Assuming "X" is "application ..."
Could you clarify what you've meant to say here? Perhaps that media type name is application/xml?
3)
If "X" is not "application" but some other type, it may not be safe
for your agent to parse the document as such.
Doesn't X just describe ( in terms of processing model ) how resource representation should be interpreted/parsed? As such, couldn't I name X part of media type name X/xml anything I want ( say blahblah/xml ), as long as agents trying to process this representation ( received via HTTP response with Content-Type header set to blahblah/xml ) are aware ( ie know how to process this representation according to instructions given by blahblah/xml ) of media type blahblah/xml?
2. EDIT
1)
This is why you should be using standard media types, rather than
custom media types -- because in the end, the media type itself is not
a driver of application behavior
Isn't a downside to using standard media types in that when agent receives a resource representation, it won't know just by checking media type value whether it semantically understands the representation, while with custom media types, agent can figure just by looking at media type value whether it knows the semantic meaning of a resource representation?
2)
This is why you should be using standard media types ...
Then I also assume we should only be using standard ( ie those registered with IANA ) rel values?
3)
Higher level application semantics are communicated through external
documentation, not the media type. Through the documentation of rels
and links and what the named values within the representation mean.
Perhaps I'm nitpicking, but ... you say higher level semantics should be communicated through external documentation and not media type, but then you note that documentation of rel values should convey higher level semantics. But aren't rel values in lots of cases ( not always, as rel values can also be independently defined, such as those registered with IANA ) considered as being part of a media type?
Thank you
To clarify, XML has no hypermedia controls. I assume you meant a hypermedia-capable XML format such as Atom (application/atom+xml).
1a) From RFC 2046 section 3:
Plain text is intended to be displayed "as-is". ... Other subtypes are to be used for enriched text in forms where application software may enhance the appearance of the text, but such software must not be required in order to get the general idea of the content.
In your example, your software agent receiving a response of text/xml may choose to enhance the display of the document (clickable links, syntax highlighting, etc). See note 1.
1b) Assuming "X" is "application" then yes, your agent may freely parse the document for hypermedia controls and use them for deciding future operation. If "X" is not "application" but some other type, it may not be safe for your agent to parse the document as such.
You're basically right. For more information, check out RFC 6839 section 4.1 and RFC 3023.
Response to edits:
A media type takes the form type/[vnd.]subtype[+suffix]. Since "type" is a little ambiguous in this context, we usually call it the "top-level media type." There's only a small handful of reasons to ever declare a new top-level media type, so unless you're absolutely sure you need it, stick with the standards: text, image, audio, video, and application. The [vnd.] is the optional vendor prefix which is used to denote non-standard subtypes. The [+suffix] is used to denote when your custom subtype is a specialization of an existing standard subtype.
If you want to define a custom XML format, use application/vnd.mymedia+xml. Using application indicates that the document is intended to be used in conjunction with programs as opposed to human display. Using vnd. indicates that it's non-standard. Using +xml means, well, that it's an XML document. And mymedia is the name of your subtype.
It's the subtype, not the top-level media type, that indicates what you refer to as the processing model. If an agent knew how to parse vnd.mymedia+xml it wouldn't (theoretically) matter if it was application/vnd.mymedia+xml or audio/vnd.mymedia+xml as both types refer to the same document format. Whether audio/vnd.mymedia+xml makes any sense or not is a separate issue.
Note 1: In practice, you can probably treat text/xml as application/xml without issue. However, you can't treat application/xml as text/xml due to the possibility of non-printable data.
You're basically on track. The media type represents the processing model for the representation. The processing model is what "knows" about hypermedia elements.
So, as mentioned, text/xml is not a hypermedia media type because raw XML has no concept of hypermedia controls. Whereas, XHTML is clearly a hypermedia media type.
The processing model based on the media type effectively represents the syntax of the representation, as well as some level of processing semantics at the MEDIA TYPE level.
What they do not do, is represent semantics at an APPLICATION level.
This is why you should be using standard media types, rather than custom media types -- because in the end, the media type itself is not a driver of application behavior.
Consider application/vnd.invoice+xml. This implies (based on the name) that this media represents some kind of type resource, such as an invoice. in contrast to simply application/xhtml+xml. The html format clearly has no "invoice" semantics, its not even implied.
By using generic media types, the clients and applications can layer their own semantics upon the representation as the application requires. Higher level application semantics are communicated through external documentation, not the media type. Through the documentation of rels and links and what the named values within the representation mean.
Addenda:
The media type is syntax, not semantics. When you get an HTML form from a request, for example, is the form for submitting address information? airport reservations? tax information? The HTML media type can represent all of these, but none of these are related to the HTML media type at all.
If you followed the "registerCar" rel, the odds are pretty high that the form you got back have something to do with registering a car, HTML has no say in it. But the details surrounding the "registerCar" rel are documented externally. There may well be markers in the representation, such as <title>Car Registration Form</title>, but, too is something delegated to the documentation. But there's no criteria that suggest that semantics of a resource representation is necessarily able to convey the semantics under which it is used.
If you got a form back with a name and address, who's name is it? Which address? If you do "GET /person/1/homeaddress", then it's fair to say that you got their home address. But introspection of the payload doesn't necessarily tell you that. It's all a matter of context.
As for media types that document rels, some do, some don't. Atom has some, HTML doesn't. HAL doesn't. IANA has a list of generic standardized rels, but those are independent of media type. They would be applicable in either HTML or HAL. They're orthogonal.
If you're going to use standardized rels, then you should stick close to the semantics as standardized, thus leveraging the standard and the wide knowledge that they bring. But in the end how your application processes different rels is up to your application.
Does any programming language provide such a thing?
Where could this be used?
For example:
note that somethingStrange is not a class, its an instance (its underlined) and this is an object diagram
Spec (section 7.3.22) says:
An instance specification is depicted using the same notation as its classifier, but in place of the classifier name appears an underlined concatenation of the instance name (if any), a colon (‘:’) and the classifier name or names.
The convention for showing multiple classifiers is to separate their names by commas.
So im stuck with "multiple classifiers".
Any language with extensional rather than intensional typing will allow such constructs.
For example, in RDF two sources could make claims about a web resource which are completely conflicting, or in a 'duck type' language an object could have all the characteristics of two otherwise unrelated types.
Extensional languages classify objects by their properties - if it has prongs it's a fork, if it's got a handle and a bowl it's a spoon, if it has both prongs and a bowl it is both a fork and a spoon.
The difference between such languages and class oriented intensional languages such as C++/Java/C# to which UML is more commonly applied, is that you don't need a spork class to define things which are both spoons and forks - whether things belong to a classifier is defined by whether they meet the requirements of the classifier.
That's multiple inheritance if you're referring to classes (except that you should use solid edges for generalization), nothing wrong with that ;)
Note that an interface is also a classifier, so also the text of your question needs a bit of refinement -- nothing wrong with generalizing more than one interface, after all.
It's is a Dependency.
Dependency is a weaker form of relationship which indicates that one class depends on another because it uses it at some point of time. One class depends on another if the latter is a parameter variable or local variable of a method of the former. This is different from an association, where an attribute of the former is an instance of the latter.
In other words your somethingStance class will use both Cat and Panzer
The below it is just an example of how it might look like
Public class SomethingStrange{
public Cat CatDependency{get;set;}
public Panzer PanzerDependency{get;set;}
}
UML does allow an object to be instance of several different classes (even if they are unrelated) at the same time. The fact that this is not the normal convention and not supported by programming languages is a different issue. UML tries to be as broad as possible even if specific technologies only can implement a subset of it.
I have been reading ASN.1 specification, but I am not quite sure what exactly does tag do in this notation schema, for example:
ETYPE-INFO-ENTRY ::= SEQUENCE {
etype [0] Int32,
salt [1] OCTET STRING OPTIONAL
}
In this representation, what information did the tags "0" and "1" convey? I had thought that the tags may serve as a indicator of the data type of the field, but it seems not, the ASN.1 specification says that the tags mainly serves as a label, is it that simple? In that sense, I can assign arbitrary tag numbers to fields, is that right? Thank you.
Tags identify types. Technically, they define types, but it may not be helpful to think of them that way.
Consider having two optional fields of type INTEGER. If they were just encoded using the tag for INTEGER, you couldn't distinguish them. By putting unique tags on them, you can.
Tagging is somewhat complicated, and this isn't the best place to try to explain them. We have two books listed on our resources page which are helpful. If you Google for them, you can find some earlier(?) editions available on-line for free. They should help you get a better handle on tags.