A specific class hierarchy must be created in order to accommodate the host.domain information which can be used to classify the AO at coarse level. The top of this hierarchy is a class named URL which must have (at least) the following attributes:
| Domain_0 | (e.g www,gopher,ftp,s700) |
|---|---|
| Domain_1 | (e.g. ncsa,telepac,inescn,di) |
| Domain_2 | (e.g. uiuc,inesc,uminho) |
| ... | (...) |
| Domain_n | (e.g. com,pt,org,edu) |
At the same time, URL's subclasses reflect the possible scheme values and even filename extensions. However, if for a given URL the value scheme + filename extension is not the name of an existent (pre-defined) class then only the scheme value is used. The following class hierarchy is a tentative illustration of this idea and specifies some possible subclasses for the HTTP class:
| URL | |||
|---|---|---|---|
| FILE | |||
| HTTP | |||
| HTTPHTML | (Html documents) | ||
| HTTPTXT | (Text documents) | ||
| HTTPPS | (Postscript documents) | ||
| HTTPDOC | (Word documents) | ||
| HTTPTEX | (TeX documents) | ||
| HTTPGIF | (Gif images) | ||
| HTTPZIP | (Zipped files) | ||
| GOPHER | ... | ||
| ... | |||
| WAIS | ... | ||
| ... | |||
| NEWS | ... | ||
| ... | |||
| TELNET | ... | ||
| ... |
Of course, other attributes may be added to the classes reflecting the specific information of their objects.