NOTE-uclp-19990120
W3C Note, 20-Jan-1999
This document is a submission to the World Wide Web Consortium from SAIC/Bellcore (see Submission Request, W3C Staff Comment).
This document is a NOTE made available by W3C for discussion only. This indicates no endorsement of its content, nor that W3C has had any editorial control in its preparation, nor that W3C has, is, or will be allocating any resources to the issues addressed by the NOTE.
The Universal Commerce Language and Protocol (UCLP) is an XML-compliant schema for tagging metadata that can be used in identifying and retrieving data residing across the Internet. The tags provide a base level of data typing while allowing industry-specific names to be defined as necessary to describe those properties and attributes which a user needs when discriminating among available choices. The introduction of data typing has been discussed as a needed extension to the XML 1.0 Recommendation, but UCLP is intended to introduce a new paradigm for dynamic data tagging for which data typing is only a required tool.
The release of the W3C XML recommendation provides a syntax for tagging data, but it is still necessary to define the content, or at least the relationships, that the tags represent. Document type definitions (DTDs) serve this purpose in standard SGML applications, but these can introduce other nontrivial challenges. One such challenge is the common effort needed to define industry-specific, standard DTDs that capture the industry content. While there are certainly examples where such DTDs have been developed and provide a useful common language, the process often requires extensive negotiation among the industry representatives and thus can be very time consuming. Once the negotiations are complete, the resulting compromises, while providing a middle ground, may not adequately satisfy individual needs or provide sufficient incentive for member organizations to fully participate. Even if initially adequate, the DTD scope and specifics must be updated to include technology advances and other changes. Here, time again becomes an issue: if users wait for agreement on DTD changes, this does not support the pace of commerce; if individuals generate modified DTDs, there is soon divergence from an unambiguous standard and point-to-point solutions result. This is the present predicament with EDI.
In the XML recommendation, DTDs are optional and this invites the creation of a new paradigm where DTDs are not needed. For such a paradigm, one needs to look for a tagging schema which captures the relevant parameters describing an object, but which can also evolve to capture changes in the marketplace in the same timeframe in which these are occurring. The system using these tags would have to be flexible in incorporating changes, would have to provide the industry domain with means to monitor and regulate changes according to their own policies, and must be sufficiently general so that advances made in one domain can be transferred to others. The technology transfer would include both growth in the hierarchy which captures content organization and improvements in the software which allow users to establish connections between entities.
With the idea of a flexible tagging schema as a major driver, a DARPA-funded project known as Web-Agile Missile Supply Chains provided the vehicle for creating both the UCLP syntax and applications that automatically tag content and then perform search and ranking on the basis of the tagged values. The traditional approach for SGML tagging is to define the entire tag set and develop the applications needed to make use of these tags before tagging the content as prescribed by the defined structure. The benefit is a predictable organization of content, but the drawback can be a rigid structure which requires considerable effort to create and is not readily amenable to changes either in the domain hierarchy or the associated class properties. The organization is meant to be unambiguous, but attempts to stretch defiinitions and structures to accommodate unplanned needs often lead to point solutions which require tailored (and often proprietary) applicatioins to decipher.
UCLP applications, on the other hand, are designed to work with as much or as little a priori structure as available, to display the structure existing at any time to both users and providers of new content, and to let the content providers dynamically extend the tagged metadata as necessary to present information they feel is needed by the consumers of the information. The goal is to capture metadata needed to discriminate between choices available through the Web (whether these be among products, data, or other entities) and to provide links back to the bulk items or their further descriptions. By developing applications which allow the definition and capture of organization to remain dynamic, the initial burden is reduced and the most useful patterns can be observed and disseminated by the application. In addition, if applications are developed to accommodate such a flexible structure, these same applications can be used in other domains by simply substituting the structure relevant to the new domain.
An example of the use of a flexible tagging structure can be seen in the cataloging of desktop computers. In the early 1990s, the properties of the computer would have included the (standard) availability of a 5-1/4" floppy drive, but no the speed of the (nonexistent) CD-ROM drive. During the intervening time, some vendor would have decided there was a competitive advantage in advertising the new CD-ROM, and that vendor would have created the first CD-ROM tag. (This could have been accomplished through use of supporting software or entered manually on the Web page by the content provider.) There would have been no need to apply to a standards body to include the new tag in a DTD, although the domain could optionally support a review team to monitor changes and suggest use within the existing structure. The vendor would have introduced the CD-ROM tag and the application would have added it to the computer domain when the generated Web page was parsed and its contents incorporated into the desktop computer's set of properties. As other vendors viewed the existence of the tag and decided the CD-ROM was an option of interest to buyers, the new tag would flourish in general use. On the other hand, as the 5-1/4" floppy disappeared, its tag could automatically be deleted from consideration. In the same way, other tags which may have been introduced but not found to be generally useful would also be purged.
Under a paradigm using the UCLP tagging, the name and the other associated attributes corresponding to a given type tag are not imposed by accumulated through use. The names represent properties describing a given class in a domain hierarchy (the class is also identified by a UCLP tag), and both the hierarchy and associated properties (the sum of which is referred to as the domain ontology) can be initially derived from standards within domain or other domain conventions. The applications which would support the growth, maintenance, and use of the domain and instances of information entered into its ontology would include the following:
The application set would support the evolution of the domain while presenting users with both guidance on how information is organized and the ability to extend it. For the DARPA project which provided the motivation for UCLP, the MISTI™ application set was developed to implement UCLP and capture real-time data use. The UCLP syntax is designed to present Web accessible information in a way that can support additional such applications.
The specification contained in this document is that found necessary to support the dynamic tagging structure and application capabilities needed for UCLP applications. The first public release of UCLP was version 2.0 in November 19971 (See Reference Section). The present document draws considerably from the 2.0 release, with the major change being that the UCLP syntax has been made compliant with XML 1.0. Though MISTI™ applications exist to make use of the tags, the metadata, whether generated using MISTI™ tools or through other means, is also accessible to any application capable of parsing XML. This is consistent with the paradigm of organizaing data in a nonproprietary manner and developing applications which provide useful functionality and also demonstrate original means to advancing Web usability.
Details of the UCLP elements are described in the rest of this document. Section 2 provides an overview of the UCLP concepts, the structure of a UCLP page, and the UCLP tags. Section 3 introduces the conventions used in the discussions of UCLP syntax. Section 4 provides detailed syntax and semantics of UCLP tags. Section 5 summarizes the details covered in this specification. Appendices follow which include an elaboration on methods and signatures, a UCLP DTD, and sample UCLP pages.
Basic terms, concepts, and interrelationships are discussed in Section 2. This includes the structure of UCLP tags and how these are used to describe Web-based information. The discussion uses the standard HTML page as its vehicle in describing the UCLP tags and explains the addition of these tags to those controlling the page's visual display. However, the tags can also be defined in the context of a mapping to a Web-accessible database, and the resulting HTML page, if it exists at all, would be dynamically generated using the UCLP/database mapping. Alternately, data may be accessed directly using UCLP - aware methods, with no physical page ever being displayed. The concept of UCLP methods is discussed further in Sections 2 and 3. The tag structure and syntax defined below is equally applicable to static pages, dynamic pages, and method use.
A UCLP page has the same structure as an HTML page, except that it uses additional tags called UCLP tags over and above the standard HTML tags. Thus, a typical UCLP page will follow the overall structure of an HTML page as follows:
<html> <head> <title> ... </title> ...other HTML tags applicable in the header area </head> <body> ...constructed using UCLP tags and standard HTML body constructs. ...restrictions apply regarding the usage of UCLP tags </body> </html>
where the HTML and UCLP tags may be intermingled in the
<body> block
as long as syntax rules for each are obeyed. The overall structure of the
body part of a
UCLP page, as illustrated in Figure 1, is:
UCLP Version 3.0 allows two types of entities:
Figure 2 shows the relationship between a domain and the properties of an object in the domain. There are two types of properties: data properties and link properties. A data property is one which includes a Property Name and a Property Value, with the Property Value being definable as a numeric value or an alphanumeric string. The data property has other optional attributes for attaching additional information (such as dimensions or privacy requirements) as part of the tagged property. Data properties are further discriminated by such characteristics as whether the value is numeric and a quantitative comparison is valid (a parameter), a string whcih contains one of a finite set of descriptors (a feature), or one of several other categories.
A link property indicates when the property content is accessible over the Web and includes the Property Name and a link to the content location. As with data properties, additional attributes can be included to further describe the property.
For a domain entity, the structure of the entity description is as follows:
Entity/Entry Declaration (UC_ENTRY tag)
One or more data properties
(UC_ID, UC_FEAT, UC_PAR, or UC_DESC
tags)
Zero or more link properties (UC_DOC, UC_OBJ, or UC_METHOD tags)
End Entity/Entry declaration (/UC_ENTRY tag)
Details of each tag are described below in Section 4.
Methods are the means by which context-specific information about a domain entry can be derived or similar information across many domain entries can be determined and compared. For example, the price of an item may depend on the quantity ordered and the required delivery schedule. Rather than having a table of static values which could be prohibitively large and difficult to update, UCLP pages can include links to available methods defined by the supplier and instructions on how the methods are used. The UC_SIGNATURE tag is the means of supplying these instructions. (See also the UC_METHOD tag description.) As shown in Figure 3, the signature resembles the description of a domain entity and, in fact, makes use of a modified form of the data property tags. The structure of signatures is as follows:
Signature Declaration (UC_SIGNATURE tag)
One or more extended data
properties (UC_ID, UC_FEAT, UC_PAR, or UC_DESC
tags) with
additional fields (SOURCE and USAGE) defining how the
data property
relates to the method
End Signature declaration (/UC_SIGNATURE tag)
Methods may be invoked manually by a user or through a UCLP-aware application. A given method can be applicable to more than one entity and more than one signature may point to the same method. In the example of the pricing method, several products can have the same price structure but one signature may define the retail price as required output of the method while another might require the price given to preferred customers. The structure of methods and signatures is designed to support this flexibility. The use of methods and signatures is described further in Appendix A.
Information comes in many varieties, from that meant for public distribution to proprietary data meant for use internally or by selected team members to restricted data requiring classified access. UCLP is not designed to specifically accommodate information classified for government-controlled access, but its design does recognize that different instance properties may require different access control. To accomplish this, UCLP uses the privacy attribute to define the access category of all information for an instance or any of its properties. The attribute is set at the page/class level and the category is inherited to other UCLP constructs unless overridden. The ability to override extends down to the level of the individual properties. Note, the privacy attribute identifies an access category but it is up to the UCLP - aware application to interpret the assigned value and to take appropriate action.
If different access categories were to exist, it is likely that multiple pages could exist for a single instance, each containing information at a different level of access or a different mix of such data. For example, a page could exist with only public data and a "sibling" page would exist with proprietary data (or possibly a mix of public and proprietary information). UCLP supports identifying a family of pages by use of a sibling tag. Thus, a page could indicate other pages with different access categories, and it would be up to the data provider to control access through location of the data server or through the UCLP application software. The syntax and inheritance of the privacy attribute and sibling tag are discussed below.
The following notations are used to describe the syntax in the discussions below.
As shown below, the UCLP tags describe the storing of information by using invisible HTML tags, i.e. tags which are ignored by HTML browers. Thus, information contained in the UCLP tags must be duplicated in HTML content if this information is to be displayed. However, the syntax could be constructed to make the stored information visible. This is illustrated in the excerpts below.
Excerpt from an HTML page that uses invisible tags:
"...This product comes in the shape of
a cube with rounded edges. <UC_DESC
name="shape" value="cube with rounded
edges">...The contents inside the UC_DESC
tag will not be displayed in the
browser."
The counterpart using visible tags is:
"...This product comes in the
<UC_DESC><name>Shape</name>of a <value> cube with
rounded
edges</value></UC_DESC>...Here the information is coded only
once. It is
visible in the browser and becomes the
content of the UC_DESC tag..."
As this example shows, either method can support the storing of information which must be captured by the UCLP. The choice of invisible tags allows UCLP-coded information to be stored as part of the source for existing Web pages without affecting the page display. While not yet investigated, it is anticipated that an accompanying style definition will allow the segregated tag syntax while removing the need for the redundant tagging presently used for display.
UCLP is designed to provide a generic standard for publishing information. Therefore, it does not specify a set list of properties (e.g. Property Name/Property Value pairs) to describe an entity but rather the UCLP tags specify types of properties for which certain data operations are valid. The properties themselves may be domain-specific, and a "seed" set of properties is provided for the user community to expand or prune through normal usage. In the tag descriptions which follow in Section 4, we provide examples from our prototype implementation to serve as a guide for usage.
The page registration tag is used to indicate that the HTML page is a UCLP page. One instance of this tag is required on a UCLP page, and it must precede all other UCLP tags on that page.
Syntax
<UC domain =
<domain> version =
<version> class =
<class>
[status =
<status>] [privacy =
<privacy>]>
zero or more UC_SIBLING tags
followed by one UC_ENTRY or
UC_SIGNATURE block
</UC>
Details
<domain> a string
This field is used to indicate the domain of discourse for which the page is being published. The list of valid domains is defined by user communities. Typical examples of domains are products, processes, organizations, people, documents, etc.
<version> 1.0 | 2.0 | 3.0
This field is used to indicate the UCLP version used by this page.
<class> a string
This field is used to specify or suggest the class name for the contents of this page. Classes are typically defined such that the instances of a class have common properties with common meanings. For example, "screw" and "nail" may be separate classes because there are significant differences in their corresponding properties (i.e. "size" for nail might be "10d" while for screw it might be "10-32"), but the differences between a wood screw and a machine screw would be indicated by a screw class attribute. However, both screw and nail may be subclasses of a higher level class of "fasteners".
The structure of classes and subclasses defined by a user community as appropriate for its domain is termed a class hierarchy. More than one class hierarchy may be needed to describe a domain, and the appropriate class name for the entity to be represented by the UCLP page may be determined by browsing through the list of domain classes and class hierarchies. When defining new classes, user communities may associate a set of recommended properties with the class. For the prototype implementation, the class name is of the form "noun/qualifiers1/qualifier2/...", where the qualifiers would indicate a type of composition relationship that cannot be adequately handled within a single noun.
<status> current|obsolete
This field is an optional field that is used to indicate the
"existence" status of the
page to the users of the page, especially, search crawlers and
gateways that search
and index UCLP pages. The default value is current.
<privacy> public | <ot
her user-defined privacy levels>
This field is optional and is used to specify the default
privacy/protection context
for the page. The default value for this field, if unspecified, is
public.
Examples of UC start tag
<UC domain="products" version="3.0" class="electronics/power
supply">
<UC domain="books" version="2.0" class="report" status="current"
privacy="company_proprietary">
<UC domain="products" version="2.0"
class="electronics/power
supply/unregulated" status="obsolete">
Purpose
It is often necessary to publish information for audiences in multiple security/ privacy contexts. For example, while the supplier might publish a UCLP page which contains general capabilities and is for public access, the detailed performance characteristics of the product may be considered proprietary and would only be accessible to firms having signed a confidentiality agreement. In this case, the supplier could publish both a public page indicating information which exists but whose proprietary values are not included on the page and a second page for which access is more limited and which contains the proprietary data. This implies that multiple UCLP pages may exist for the same item, and a link is needed to indicate the URLs of these clones/sibling pages.
The sibling tag is an empty tag used on the UCLP page of an object to point to other UCLP pages which contain different privacy level data for the same object. The security levels and their hierarchy are defined by the user. There is typically one UC_SIBLING tag for each security level referenced on a UCLP page, and the sibling tags should come before any other tags in a UC block.
Syntax
<UC_SIBLING privacy =
<privacy> url =
<url>/>
Details
<privacy> public
| <other user defined privacy levels>
This field is used to specify the privacy/security context of the
sibling page
which can be found at <url>.
<url> a URL
This field is used to specify the URL of the sibling page.
Examples
<UC_SIBLING privacy="medium"
&
nbsp;url="http://mycom.com/medsec/power.html"/>
<UC_SIBLING privacy="high"
url="http://mycom.black.com/highsec/power.html"/>
Purpose
The entry tag is used to add an instance of a domain entity. The entry block will include the specification of properties of this instance, and the name associated with the entry is returned in response to a search over UCLP pages. A data property must be the first property element in a UC_ENTRY block.
Syntax
<UC_ENTRY name =
<name> [realization_state =
<r_state>]
[privacy = <privacy>]
>
... property elements ...
</UC_ENTRY>
Details
<name> a string
This field is used to name the entry.
<r_state> a string
The realization state specifies the life cycle phase of the entry. The set of valid values for the realization state depends on the domain of discourse and is defined by user communities. As an example, the following realization states (and their indication about the product state) are defined for the products domain in our prototype implementation:
<privacy> public |
<other user defined privacy levels>
This field is optional and is used to specify a privacy/protection
context for all UCLP
property tags and their fields contained in this entry block. The
default value is that
specified in the privacy field of the UC tag on the page containing
this entry block. If no
privacy level is specified on the UC tag, the default is
public.
Examples
<UC_ENTRY name="new RF cover"
realization_state="available">
..elements..
</UC_ENTRY>
<UC_ENTRY name="UCLP" realization_state="draft">
..elements..
</UC_ENTRY>
Purpose
The identification tag is a data property tag used to specify properties that may uniquely identify the entry from all other instances of its class. An entry can have zero or more such tags. The identification tag is an empty tag.
Syntax
<UC_ID name =
<name> value = <value>
[privacy = <privacy>]/>
Details
<name> a string
This field is used to specify the name of the ID property. The
following are some examples
of ID names used for products in our prototype implementation:
<value> a string
This field is used to specify the value corresponding to
<name>. The value always will be treated as a
character string.
<privacy>
public | <other user defined privacy
levels>
This field is optional and is used to specify a privacy/protection
context for the
value field in this instance of this UCLP tag.
The default value is specified
using the privacy field on the UC_ENTRY tag in which this tag
appears. If no privacy level is
specified on the UC_ENTRY tag, the default is that specified on the
UC tag of this page. If no
privacy level is specified on either the UC or UC_ENTRY tags, the
default is public.
Examples
<UC_ID name="manufacturer model name"
value="ALT123-XL"/>
<UC_ID name="ISBN" value="087819-454-1"/>
Purpose
The feature tag is a data property tag used to specify qualitative properties of an entry. Qualitative properties are those that take values from some enumerated set. These values are expected to be words or short phrases and not elaborate descriptive texts. The feature tag is an empty tag.
Syntax
<UC_FEAT name =
<name> value = <value>
[privacy = <privacy>]/>
Details
<name> a string
This field is used to specify the name of the feature. The
following are examples of FEAT
names for products from our prototype implementation:
Feature Name
Typical Values
<value> a string | a list of
strings
This field is used to specify one or more values corresponding to
the feature name. If <value>
is a list, the elements of the list should be separated by a
semicolon (;).
<privacy>
public | <other user defined privacy
levels>
This field is optional and is used to specify a privacy/protection
context for the value
field in this instance of this UCLP tag. The default value is
specified using the privacy field
on the UC_ENTRY tag in which this tag appears. If no privacy level
is specified on the UC_ENTRY
tag, the default is that specified on the UC tag of this page. If
no privacy level is specified
on either the UC or UC_ENTRY tags, the default is
public.
Examples
<UC_FEAT name="Qualifiedto" value="ISO9000;
mil-std-9858A"/>
<UC_FEAT name="authentication" value="original"/>
Purpose
The parameter tag is a data property tag used to define properties that take quantitative or parametric values or, simply put, numeric values that can be compared using arithmetic operators such as greater than, less than, etc. For example, length, weight, and price are parametric properties. The parameter tag is an empty tag.
Syntax
<UC_PAR name =
<name> value = <value>
[units = <units>]
&
nbsp; [tolerance
= <tolerance>] [privacy =
<privacy>]/>
Details
<name> a string
This field is used to specify the name of the parameter.
<value> a number, list of numbers,
range of numbers, or combination
This field is used to specify one or more values corresponding to
the parameter name. If <value> is a list,
the elements of the list should be separated by a semicolon (;).
If <value> is a range, then
the range limits should be separated by a colon (:).
<units> a string
This field is used to specify the dimensional units in which the
parameter value is expressed.
This is optional and there is no default value.
<tolerance> a tolerance-specific
format
This field is used when the parameter value should not be taken as
an exact value. This string
specifies the applicable band around the nominal value specified in
<value>. The string
should be in one of the following formats where <x> and
<y> are numbers.
| Format |
| ||
| if tolerance = | for value = | then implied range is | |
| "+-x" | "+-0.1" | 1.0 | 0.9 to 1.1 |
| "+x -y" | "+0.2 >-0.1" | 1.0 | 0.9 to 1.2 |
| "+-x%" | "+-2%" | 10.0 | 9.8 to 10.2 |
| "+x% -y%" | "+3% -2%" | 10.0 | 9.8 to 10.3 |
<privacy> public | <ot
her user defined privacy levels>
This field is optional and is used to specify a privacy/protection
context for the value,
units, and tolerance fields in this
instance of this UCLP tag. The
default value is specified using the privacy field on the UC_ENTRY
tag in which this tag appears.
If no privacy level is specified on the UC_ENTRY tag, the default
is that specified on the UC tag
of this page. If no privacy level is specified on either the UC or
UC_ENTRY tags, the default is
public.
Examples
<UC_PAR name="weight" value="20" units="lbs"/>
<UC_PAR name="length" value="20" tolerance="+0.0 -0.25"/>
<UC_PAR name="price" value="39.95" units="US$"
privacy="restricted"/>
To express that available capacity can be 20, or 30 through 40, or
60, we may use the following
statement:
<UC_PAR name="available capacity" value="20;30:40;60"/>
Purpose
The description tag is a data property tag used to specify properties that take short descriptive text for their values. The description tag is an empty tag.
Syntax
<UC_DESC name =
<name> value = <value>
[privacy = <privacy>]/>
Details
<name> a string
This field is used to specify the name of the description. The
following are some examples
of descriptive properties for products from our prototype
implementation:
value> a string <name>.
The value always will be treated as a character string.
<privacy>
public | <other user defined privacy
levels>
This field is optional and is used to specify a privacy/protection
context for the value
field in this instance of this UCLP tag. The default value is
specified using the privacy field
on the UC_ENTRY tag in which this tag appears. If no privacy level
is specified on the UC_ENTRY
tag, the default is that specified on the UC tag of this page. If no
privacy level is specified
on either the UC or UC_ENTRY tags, the default is
public.
Examples
<UC_DESC name="Shape" value="A cube with rounded
edges"/>
<UC_DESC name="surface"
value="milled, buffed and
polished with emery 100"/>
Purpose
The document tag is a link property tag used to link auxiliary documents with an entry. These documents may provide detailed and/or specialized information about the entry. For example, an engineering drawing from a CAD tool,
Syntax
<UC_DOC name =
<name> [linktype = <linktype>]
[href = <doc_url>]
[privacy =
<privacy>]/ >
Details
<name> a string
This field is used to associate a name, type, or other useful
descriptor with the document.
<linktype> manual |
hotlink
This field is optional and is used to specify the nature of the
link to the document. The
value manual is used if
<doc_url> provides information for
retrieving the document for which a human is needed in the loop.
For example, manual would be
used if documents were being obtained through phone, email, or fax.
The value hotlink
is used if the document can be retrieved directly by invoking the
<doc_url>. The
default value is hotlink. Additional
<linktype> field values may be
added by the user community.
<doc_url> a URL
This field is optional and is used to specify the URL associated
with the document. This is
used in conjunction with the <linktype> as described
above.
<privacy> public |
<other user defined privacy levels>
This field is optional and is used to specify a privacy/protection
context for the auxiliary
document at <doc_url>. The default value
is specified using the privacy field
on the UC_ENTRY tag in which this tag appears. If no privacy level
is specified on the UC_ENTRY
tag, the default is that specified on the UC tag of this page. If
no privacy level is specified
on either the UC or UC_ENTRY tags, the default is
public.
Examples
<UC_DOC name="CAD drawing"
linktype="hotlink"
href="h
ttp://mysite.com/fuse.cad" />
<UC_DOC name="technical specs"
linktype="manual"
href="h
ttp://mysite.com/specs/powersupply/fax.html" />
Purpose
The object tag is a link property tag used to link the current entry with related entries/objects in other UCLP pages. The link tag is an empty tag.
Syntax
<UC_OBJ name =
<name> rel = <rel> href =
<obj_url>
&
nbsp; [privacy =
<privacy>]/>
Details
<name> a string
This field is used to name the related object within the context of
the current entry.
<rel> a string
This field is used to specify the type of relationship between the
current entry and the
indicated object. The following is a sample of relationships (and
their meanings) for the
products domain from our prototype implementation:
<obj_url> a URL
This is the URL of the (UCLP) page that contains the related
object/entry.
<privacy> public |
<other user defined privacy levels>
This field is optional and is used to specify a privacy/protection
context of the related object
which can be found at <obj_url>. The
default value is specified using the
privacy field on the UC_ENTRY tag in which this tag appears. If no
privacy level is specified on
the UC_ENTRY tag, the default is that specified on the UC tag of
this page. If no privacy level
is specified on either the UC or UC_ENTRY tags, the default is
public.
Examples
<UC_OBJ name="fuze" rel="Component"
href="http://mysite.com/a1721.h
tml"/>
Purpose
The method tag is a link property tag used to associate a method with an entry. The method tag is an empty tag.
Syntax
<UC_METHOD name =
<name> signature_href =
<sig_url>
href =
<href> http_method =
<getpost>
[privacy =
<privacy>]/>
Details
<name> a string
This field is used to name the method. While the method name is not
restricted, it is expected
that user communities will define a list of standard names for
methods such as "price",
"ordering", etc.
<sig_url> a URL
This field is used to specify the URL of the UCLP page that
contains the method signature details.
(Also see UC_SIGNATURE description). The signature defines the
input and output arguments used
by the method as related to the parent entry.
<href> a URL
This field is used to specify a URL at which the method can be
invoked. <href>may include a
fully instantiated query string or provide the base URL to which
data is submitted per http_method.
<getpost> get |
post
This field is used to specify the HTTP method (not related to UCLP
method) used to send a form to
a processing agent.
<privacy> public |
<other user defined privacy levels>
This field is optional and is used to specify a privacy/protection
context for invoking the
method. The default is public.
Examples
<UC_METHOD name="price"
signature_href="http://www.mycom.com/price.html"
href="http://www.mysite.com/price.asp?entry=c"
http_method="get"
privacy="proprietary"/>
<UC_METHOD name="price"
signature_href="http://www.mycom.com/color.html"
href="http://www.mysite.com/cgi-bin/query"http_meth
od="post"/>
Purpose
The signature tag is used to describe the interface details of a method. The interface is described in terms of functional description, input and output arguments, and exception handling.
Syntax
<UC_SIGNATURE name
= <name> [privacy =
<privacy>]>
..
..<extended data property description>
...
</UC_SIGNATURE>
Details
<name> a string
This field is used to specify the name of the signature.
<privacy> public
| <other user defined privacy levels>
This field is optional and is used to specify a privacy/protection
context for invoking the
method. The default is public.
<extended data property
description>
The extended data property description consists of a set of UC data
property tags and is used to
define the arguments related to the method. There is one extended
description tag for each
argument. The syntax for extended descriptions of input properties
(UCXI_xxx) is
the same as the corresponding data property syntax except for (1)
the addition of the source
and usage fields and (2) the absence of the
privacy field,
which has no meaning in the context of a signature. The extended
syntax for method input arguments
is:
<UCXI_ID &
nbsp;name = <name> source =
<source> [value =
<value>]
usage = <usagei>
/>
<UCXI_FEAT name =
<name> source =
<source> [value =
<value>]
usage = <usagei>
/>
<UCXI_PAR name =
<name> source = <source>
[value = <value>]
[units = <units>] [tolerance
= <tolerance>]
usage = <usagei>
/>
<UCXI_DESC name =
<name> source =
<source> [value = <value>]
usage =
<usagei>/>
The extended syntax for method output arguments
(UCXO_xxx) is abbreviated to include only the name
and usage associated with output arguments of the various types.
The output returned
by a method would tag results using the corresponding data property
tags.
<UCXO_ID
name = <name> usage =
<usageo> />
<UCXO_FEAT name =
<name> usage =
<usageo>/>
<UCXO_PAR name = <
;name> usage = <usageo>
/>
<UCXO_DESC name =
<name> usage =
<usageo>/>
Refer to the respective sections for the base syntax of each
data property tag.
Here we will describe only the source field and
the respective
interpretations of the value field and the
usage field.
<source>
constant |
context | user |
profile
This field is used to specify from where the input argument will
get its value. The
following defines the relationship between
<source> and <value>
and how
default values are assigned:
<source>
<value>
Default Value
constant <some entry>
A default value is
provided and may not be overridden.
context <not supp
lied> The default value is the
value of the property <name> on the UCLP page
from
which this signature was referenced.
<some
entry> A valid
entry for <value> is any property name appearing
on the UCLP
page
from which this signature was referenced and the default value
is value
corresponding to that property name.
user
<not
supplied> There is no
default value.
<some
entry> The
entry is the default value.
profile <not supplied
> The default
value is the value of the property <name> on the
UCLP profile
pag
e corresponding to the user who invokes the method.
<some
entry> A val
id entry for <value> is any property name
appearing on the UCLP
profile page corresponding to the user
who invokes the method and the
default
value is value corresponding to that property name.
Except for source = constant, any default
value may be overridden by the user.
For source = context, the indicated property
must appear on the UCLP page from which the
signature is referenced or this will be considered an error. For
source = profile, if the
indicated profile property does not appear on a user´s profile
page, the argument will be treated the same way
as if source = user. The default value is
user.
<usagei> required |
optional | hidden
This field is used to specify the usage of the input argument as
defined in the following:
| Value | Meaning | ||
| required | A required input field. | ||
| optional | An optional input field. | ||
| hidden | A hidden input field which will not show up on browsers. |
required.
<usageo> guaranteed |
optional | status
This field is used to specify the usage of the output argument as
defined in the following:
| Value | Meaning | ||
| guaranteed | A field containing result/output values after every successful method call. | ||
| optional | An optional input field. | ||
| status | A field which will contain return value(s) for the method execution. |
optional.
Examples
<UC_SIGNATURE name="approx_price" privacy="proprietary">
<UCXI_PAR name="quantity" source="user" value="1"
usage="required" />
<UCXI_FEAT name="item_color" source="context" value="color"
usage="optional" />
<UCXI_ID name="manufacturer" source="context"
usage="optional" />
<UCXO_PAR name="price"
usage="guaranteed" />
<UCXO_PAR name="discount"
usage="optional" />
<UCXI_DESC name="precision"
source="constant" value="low"
usage="hidden" />
<UCXO_PAR name="error code"
usage="status" />
</UC_SIGNATURE>
UCLP is an XML-compliant language and protocol which enables information on domains, such as products, processes, and organizations, to be published in a rich, structured form. The form facilitates search, retrieval, and exchange of the information through the use of constructs defined within UCLP and designed to allow data objects to be created for processing properties, methods, and associations. Using UCLP, Web-distributed object models can be defined with which complex constructs (e.g., designs, systems, organizations) can be built and evolved. In effect, UCLP provides a powerful framework for information management and exchange over the Web.
This document has provided a formal specification for the UCLP tagging schema, including explanations of the structure and syntax of UCLP, examples of usage of each property tag, and appendices that elaborate on methods and present example UCLP-tagged pages. Also included as an appendix is a DTD for the UCLP tags.
As indicated throughout the discussion, specific items such as actual parameter and feature names have been defined for the MISTI™ prototype, but these are not set by the UCLP syntax, and these conventions need to be defined by the respective user communities. In the prototype system, the conventions defined for the missile industry are stored and available from the MISTI™ gateway; for other user communities, a gateway server would be identified to serve that domain.
1 Universal Commerce Language and Protocol (UCLP) - A Tutorial Introduction, Version 2.0, SAIC Report No. 97/1072, November 1997. This document has been posted on the MISTI ™ Web site at http://misti.apo.saic.com/uclptutor/
Much of the power of UCLP is derived from its support of methods. Methods are standard Web application code which is executed via a URL, where the URL may include a query string if argument passing to the method is necessary. For this document, the discussion is confined to the http protocol, but the methodology is generally intended to apply to any protocol supported by commercial Web browsers.
The purpose of methods is to provide a means to query the provider of UCLP pages for additional information that is not contained on the page. It is anticipated that such information would be either time sensitive (and methods would provide a means to query for the current value) or depend on the method user´s identity or specific requirements (and so would not be appropriate or feasible for general publication). While this can presently be accomplished on an individual levelby using an HTML link, it is important to understand the additional capability provided by a UCLP-tagged method. With an HTML link, the user clicks the link and then all processing, from input requests through display of results, is controlled by the remote server. Clicking on the link invokes only that remote processing and if the user needs to get similar information from several sources, each must be invoked in turn and the results must be collated by the user. Additionally, the existence of the link is only apparent when viewing the parent Web page and this page must be accessed before the link can be activated.
The UCLP tagging of methods establishes a tighter bond to the UCLP description of an item than exists for a simple hyperlink, and this is used to condense the data gathering process. First, the tagged information can be crawled and thus the identity and location of available methods are known at the crawler´s server. As with other UCLP properties, every content provider would be able to create new methods and could use the available list as a guide to what information is provided by other participants in a domain. One attribute of a tagged method would be the location of its signature. This signature defines the input arguments to and outputs returned from a method execution. It specifies which data exchanges are required, which are optional, and those preset and not available for user override. It also provides a mapping between the method arguments and tagged content on the UCLP page. Thus, sufficient information would be available for a UCLP-aware application to coordinate invoking a set of user-specified methods and then collating the results for a display which is meaningful to the user. The tagging of methods on an item´s page along with the signature mapping of the method inputs to the page content shortens the data input process while reducing the errors associated with manual transfer of information. Also, by having the application manage user input to several methods, the consistency of the input can be improved while reducing the total effort required of the user.
As an example, suppose a user needs to collect information from various suppliers on bulk pricing of a mounting bracket. An application could be written to take the list of candidate mounting brackets collected through a search of UCLP-compliant pages and then access the corresponding pricing methods. The application would provide a uniform interface through which to collect required inputs (such as quantity and date required) and combine these with values identified through mappings to the individual metadata (such as individual part numbers). The application would construct the required queries, invoke the methods, and then parse the results (again using signature information) for display of the prices in the original candidate list.
Methods are intended to be used interchangeably by both human users and UCLP-aware applications. Thus, while the metadata tagging must support the calling server requirements for accessing the method, passing an argument string, and receiving its output, there is nothing to preclude a method from being callable through a hyperlink on the item´s page for more nominal processing through the method server. In this way, methods can support dual use and preclude the need for separate scripts to be maintained by the content provider.
As discussed in the Introduction, the focus of UCLP is to create a dynamic approach to tagging which does not require a formal DTD of the property names and their corresponding attribute names. However, a DTD can be written for UCLP itself and is presented below. Samples included in Appendix C have been validated against this DTD.
<?xml version="1.0" ?>
<!DOCTYPE UCLP [
<!ENTITY lt "&#60;" >
<!ENTITY gt ">" >
<!ENTITY amp "&#38;" >
<!ENTITY apos "'" >
<!ENTITY quot '"' >
<!ENTITY % ucName "name CDATA #REQUIRED" >
<!ENTITY % ucValue "value CDATA #REQUIRED" >
<!ENTITY % ucHRef "href CDATA #REQUIRED" >
<!-- The default for "privacy" is set to "public", but this will be
overridden by the privacy of the parent tag, if specified. -->
<!ENTITY % ucPrivacy "privacy CDATA 'public'" >
<!ENTITY % ucxSource "source (constant | context | user |
profile) 'user'">
<!ENTITY % ucxValue "value CDATA #IMPLIED" >
<!ENTITY % ucxiUsage "usage (required | optional | hidden)
'required'" >
<!ENTITY % ucxoUsage "usage (guaranteed | optional | status)
'optional'" >
<!-- The UC content spec limits UC to only one Entry or Signature
block. -->
<!-- "status" choices given in enumerated list may be too limiting. -->
<!ELEMENT UC ((UC_SIBLING)*, (UC_ENTRY | UC_SIGNATURE)) >
<!ATTLIST UC
domain CDATA #REQUIRED
version (1.0|2.0|3.0) "3.0"
class CDATA #REQUIRED
status (current|obsolete) "current"
%ucPrivacy; >
<!ELEMENT UC_SIBLING EMPTY >
<!ATTLIST UC_SIBLING
privacy CDATA #REQUIRED
url CDATA #REQUIRED >
<!-- The UC_ENTRY content spec requires at least one ID, FEAT, PAR, or
DESC
before an OBJ or METHOD tag. -->
<!-- "realization_state" choices given in enumerated list may be too
limiting.
-->
<!ELEMENT UC_ENTRY ( ( UC_ID | UC_FEAT | UC_PAR | UC_DESC ),
( UC_ID | UC_FEAT | UC_PAR | UC_DESC | UC_DOC |
UC_OBJ
<!ATTLIST UC_ENTRY
%ucName;
realization_state (available | design | discontinued) "available"
%ucPrivacy;
>
<!-- The attribute type for "value" is set to CDATA, but it could be
replaced
with an enumerated list specific to the domain. -->
<!ELEMENT UC_ID EMPTY >
<!ATTLIST UC_ID
%ucName;
%ucValue;
%ucPrivacy; >
<!-- The attribute type for "value" is set to CDATA, but it could be
replaced
with an enumerated list specific to the domain. -->
<!ELEMENT UC_FEAT EMPTY >
<!ATTLIST UC_FEAT
%ucName;
%ucValue;
%ucPrivacy; >
<!-- The attribute type for "units" is set to CDATA, but it could be
replaced
with an enumerated list specific to the domain. -->
<!ELEMENT UC_PAR EMPTY >
<!ATTLIST UC_PAR
%ucName;
%ucValue;
units CDATA #IMPLIED
tolerance CDATA #IMPLIED
%ucPrivacy; >
<!ELEMENT UC_DESC EMPTY >
<!ATTLIST UC_DESC
%ucName;
%ucValue;
%ucPrivacy; >
<!ELEMENT UC_DOC EMPTY >
<!ATTLIST UC_DOC
%ucName;
linktype (manual | hotlink) "hotlink"
%ucHRef;
%ucPrivacy; >
<!ELEMENT UC_OBJ EMPTY >
<!-- The following enumerated list for "rel" corresponds to the UCLP 3.0
specification but may be too restrictive for general use.
(Ensemble | Ancestor | Descendent | Component | Accessories |
Alternatives)
Below, it is replaced by CDATA. -->
<!ATTLIST UC_OBJ
%ucName;
rel CDATA #REQUIRED
%ucHRef;
%ucPrivacy; >
<!ELEMENT UC_METHOD EMPTY >
<!ATTLIST UC_METHOD
%ucName;
signature_href CDATA #REQUIRED
%ucHRef;
http_method (get | post) #REQUIRED
%ucPrivacy; >
<!-- The attribute type for "value" is set to CDATA, but it could be
replaced
with an enumerated list specific to the domain. -->
<!ELEMENT UCXI_ID EMPTY >
<!ATTLIST UCXI_ID
%ucName;
%ucxSource;
%ucxValue;
%ucxiUsage; >
<!ELEMENT UCXO_ID EMPTY >
<!ATTLIST UCXO_ID
%ucName;
%ucxoUsage; >
<!-- The attribute type for "value" is set to CDATA, but it could be
replaced
with an enumerated list specific to the domain. -->
<!ELEMENT UCXI_FEAT EMPTY >
<!ATTLIST UCXI_FEAT
%ucName;
%ucxSource;
%ucxValue;
%ucxiUsage; >
<!ELEMENT UCXO_FEAT EMPTY >
<!ATTLIST UCXO_FEAT
%ucName;
%ucxoUsage; >
<!-- The attribute type for "units" is set to CDATA, but it could be
replaced
with an enumerated list specific to the domain. -->
<!ELEMENT UCXI_PAR EMPTY >
<!ATTLIST UCXI_PAR
%ucName;
%ucxSource;
%ucxValue;
units CDATA #IMPLIED
tolerance CDATA #IMPLIED
%ucxiUsage; >
<!ELEMENT UCXO_PAR EMPTY >
<!ATTLIST UCXO_PAR
%ucName;
%ucxoUsage; >
<!ELEMENT UCXI_DESC EMPTY >
<!ATTLIST UCXI_DESC
%ucName;
%ucxSource;
%ucxValue;
%ucxiUsage; >
<!ELEMENT UCXO_DESC EMPTY >
<!ATTLIST UCXO_DESC
%ucName;
%ucxoUsage; >
<!ELEMENT UC_SIGNATURE ( ( UCXI_ID | UCXI_FEAT | UCXI_PAR | UCXI_DESC
| UCXO_ID | UCXO_FEAT | UCXO_PAR | UCXO_DESC
)+ ) >
<!ATTLIST UC_SIGNATURE
%ucName;
%ucPrivacy; >
]>
The following are two examples of Web pages containing UCLP tags. The pages were generated using MISTI ™ page generators and, as such, the UCLP tags (shown in bold) are interspersed with HTML needed to create the visual page. However, the UCLP tags could be grouped together, and either method is equally valid as long the order of the tags and the element content follow the specification contained in this document.
The examples show two diverse uses of the same tagging schema. Each is catalogued under a different domain ontology, but both domains are serviced by the same application software, whose purpose it is to dynamically adjust the domain description to meet changing needs of the respective user communities. Example 1-Integrated circuit
<HTML> <HEAD> <TITLE>IC/Converter/Analog to Digital/SM</TITLE> <meta name="GENERATOR" content="UCLP On-Line"> <meta name="GENERATORINFO" content="works|IC/Converter/Analog to Digital/SM||#ffffff|http://www.analog.com/images/headers/logo_small.gif||http: //www.analog.com/product/Product_Center.html|Analog Devices Online Product Center|Analog Devices AD10242 Dual Channel, 12-Bit, 40 MSPS MCM ADC with Analog Input Signal Conditioning"> <META NAME="Description" Content="Analog Devices AD10242 Dual Channel, 12-Bit, 40 MSPS MCM ADC with Analog Input Signal Conditioning"> </HEAD> <BODY BGCOLOR="#ffffff"> <UC domain="Products" version="2.0" class="IC/Converter/Analog to Digital/SM" status="current"> <UC_ENTRY name="AD10242" realization_state="Available"> <IMG SRC="http://www.analog.com/images/headers/logo_small.gif" ALIGN=LEFT ALIGN=TOP><BR CLEAR="ALL"><HR> <center><H2>IC/Converter/Analog to Digital/SM</H2></center> <p> <TABLE WIDTH=100% BORDER=0> <TR> <TD ALIGN=CENTER VALIGN=CENTER> <FONT SIZE=4><b>Analog Devices AD10242 Dual Channel, 12-Bit, 40 MSPS MCM ADC with Analog Input Signal Conditioning</b></FONT> </TD> <TD ALIGN=CENTER VALIGN=CENTER> </TD> </TR></TABLE> <p> <BR CLEAR="ALL"> <HR SIZE="3"> <p> <BR CLEAR="ALL"> <TABLE BORDER=1 WIDTH=100%> <TR><TD ALIGN=CENTER COLSPAN=4 BGCOLOR=#00FFFF><B>General Information</B></TD></TR> <TR><TD>Supplier Hotlink</TD> <TD COLSPAN=2><A HREF="http://www.hh.avnet.com/">http://www.hh.avnet.com/</A></TD> ; <UC_DOC name="Supplier Hotlink" href="http://www.hh.avnet.com/" linktype="hotlink"/> </TR> <TR><TD>Supplier Phone Number</TD><TD COLSPAN=2>800-332-8638</TD></TR> <UC_ID name="Supplier Phone Number" value="800-332-8638"/> <TR><TD>Supplier Name</TD><TD COLSPAN=2>Hamilton-Hallmark</TD></TR> <UC_ID name="Supplier Name" value="Hamilton-Hallmark"/> <TR><TD>Manufacturer Name</TD><TD COLSPAN=2>Analog Devices Incorporated</TD></TR> <UC_ID name="Manufacturer Name" value="Analog Devices Incorporated"/> <TR><TD>Items Per Unit Of Issue</TD><TD>1</TD> <UC_PAR name="Items Per Unit Of Issue" value="1"/> </TR> <TR><TD>QualifiedTo</TD><TD COLSPAN=2>MIL-STD-883B</TD></TR> <UC_FEAT name="QualifiedTo" value="MIL-STD-883B"/> <TR><TD>Manufacturer Model / Part Number</TD><TD COLSPAN=2>AD10242</TD></TR> <UC_ID name="Manufacturer Model / Part Number" value="AD10242"/> <TR><TD>Product Name</TD><TD COLSPAN=2>Dual, 12-Bit, 40 MSPS MCM Analog-to- Digital Converter with Analog Input Signal Conditioning</TD></TR> <UC_ID name="Product Name" value="Dual, 12-Bit, 40 MSPS MCM Analog-to-Digital Converter with Analog Input Signal Conditioning"/> <TR><TD>Supplier E-mail</TD><TD COLSPAN=2>hh.express@hh.avnet.com</TD></TR> <UC_ID name="Supplier E-mail" value="hh.express@hh.avnet.com"/> <TR><TD>Manufacturers Data Sheet</TD> <TD COLSPAN=2><A HREF="http://products.analog.com/products/info.asp?product=AD10242">http://p ro ducts.analog.com/products/info.asp?product=AD10242</A></TD> <UC_DOC name="Manufacturers Data Sheet" href="http://products.analog.com/products/info.asp?product=AD10242 " linktype="hotlink"/> </TR> <TR><TD ALIGN=CENTER COLSPAN=4 BGCOLOR=#80FFFF><B>Item Specific Information</B></TD></TR> <TR><TD>Input Capacitance</TD><TD>4</TD> <TD>pF</TD> <TD></TD> <UC_PAR name="Input Capacitance" value="4" units="pF" tolerance=""/> </TR> <TR><TD>Input Resistance</TD><TD>100;200;400</TD> <TD>Ohms</TD> <TD></TD> <UC_PAR name="Input Resistance" value="100;200;400" units="Ohms" tolerance=""/> </TR> <TR><TD>Analog Input</TD><TD>1;2;4</TD> <TD>Vp-p</TD> <TD></TD> <UC_PAR name="Analog Input" value="1;2;4" units="Vp-p" tolerance=""/> </TR> <TR><TD>Conversion Rate</TD><TD>40</TD> <TD>MSPS</TD> <TD></TD> <UC_PAR name="Conversion Rate" value="40" units="MSPS" tolerance=""/> </TR> <TR><TD>Resolution</TD><TD>12</TD> <TD>Bits</TD> <TD></TD> <UC_PAR name="Resolution" value="12" units="Bits" tolerance=""/> </TR> <TR><TD>Input Range</TD><TD COLSPAN=2>Selectable Bipolar and Unipolar</TD></TR> <UC_FEAT name="Input Range" value="Selectable Bipolar and Unipolar"/> <TR><TD>Analog Input Bandwidth</TD><TD>60</TD> <TD>MHz</TD> <TD></TD> <UC_PAR name="Analog Input Bandwidth" value="60" units="MHz" tolerance=""/> </TR> <TR><TD>Matching</TD><TD COLSPAN=2>Trimmed Channel-Channel</TD></TR> <UC_FEAT name="Matching" value="Trimmed Channel-Channel"/> <TR><TD ALIGN=CENTER COLSPAN=4 BGCOLOR=#00FFFF><B>Additional Attributes</B></TD></TR> <TR><TD WIDTH=40% >Number of Channels</TD><TD COLSPAN=2>2</TD></TR> <UC_FEAT name="Number of Channels" value="2"/> <TR><TD WIDTH=40% >Signal Conditioning</TD><TD COLSPAN=2>Flexible Analog Input Signal Conditioning</TD></TR> <UC_FEAT name="Signal Conditioning" value="Flexible Analog Input Signal Conditioning"/> </TABLE><p> <p><center><A HREF="http://www.analog.com/product/Product_Center.html">Analog Devices Online Product Center</A></center> </UC_ENTRY></UC><BR><BR></BODY></HTML> Example 2-Milling process <HTML> <HEAD> <TITLE>Machining/Milling</TITLE> <meta name="GENERATOR" content="UCLP On-Line"> <meta name="GENERATORINFO" content="works|Machining/Milling||#ffffff|||||C.G. TECH INC, is a custom manufacturer of precision machined and sheet metal parts and assemblies. Using the latest in CNC manufacturing technology, C.G. Tech supplies custom precision parts to the telecommunications, aerospace, satellite, medical, biomedical, electronic, computer and automotive industries throughout the United States. C.G. Tech is uniquely qualified to provide manufacturing with the in house capability of combining machining and sheet metal operations for custom parts and assemblies. "> <META NAME="Description" Content="C.G. TECH INC, is a custom manufacturer of precision machined and sheet metal parts and assemblies. Using the latest in CNC manufacturing technology, C.G. Tech supplies custom precision parts to the telecommunications, aerospace, satellite, medical, biomedical, electronic, computer and automotive industries throughout the United States. C.G. Tech is uniquely qualified to provide manufacturing with the in house capability of combining machining and sheet metal operations for custom parts and assemblies. "> </HEAD> <BODY BGCOLOR="#ffffff"> <UC domain="Processes" version="2.0" class="Machining/Milling" status="current"> <UC_ENTRY name="Milling" realization_state="available"> <center><H2>Machining/Milling</H2></center> <p> <TABLE WIDTH=100% BORDER=0> <TR> <TD ALIGN=CENTER VALIGN=CENTER> <FONT SIZE=4><b>C.G. TECH INC, is a custom manufacturer of precision machined and sheet metal parts and assemblies. Using the latest in CNC manufacturing technology, C.G. Tech supplies custom precision parts to the telecommunications, aerospace, satellite, medical, biomedical, electronic, computer and automotive industries throughout the United States. C.G. Tech is uniquely qualified to provide manufacturing with the in house capability of combining machining and sheet metal operations for custom parts and assemblies. </b></FONT> </TD> <TD ALIGN=CENTER VALIGN=CENTER> </TD> </TR></TABLE> <p> <BR CLEAR="ALL"> <HR SIZE="3"> <p> <BR CLEAR="ALL"> <TABLE BORDER=1 WIDTH=100%> <TR><TD ALIGN=CENTER COLSPAN=4 BGCOLOR=#00FFFF><B>General Information</B></TD></TR> <TR><TD>Supplier Name</TD><TD COLSPAN=2>C.G. Tech Inc.</TD></TR> <UC_ID name="Supplier Name" value="C.G. Tech Inc."/> <TR><TD>Supplier Phone Number</TD><TD COLSPAN=2>602-492-9400</TD></TR> <UC_ID name="Supplier Phone Number" value="602-492-9400"/> <TR><TD>Supplier Fax Number</TD><TD COLSPAN=2>602-492-9071</TD></TR> <UC_ID name="Supplier Fax Number" value="602-492-9071"/> <TR><TD>Supplier E-mail</TD><TD COLSPAN=2>cgtech@phnx.uswest.net</TD></TR> <UC_ID name="Supplier E-mail" value="cgtech@phnx.uswest.net"/> <TR><TD>Supplier Hot Link</TD> <TD COLSPAN=2><A HREF=" http://www.cgtechinc.com"> http://www.cgtechinc.com</A></TD> <UC_DOC name="Supplier Hot Link" href=" http://www.cgtechinc.com" linktype="hotlink"/> </TR> <TR><TD>Qualified To</TD><TD COLSPAN=2>ISO 9002;MIL-STD- 45662;MIL-STD-45208</TD></TR> <UC_ID name="Qualified To" value="ISO 9002;MIL-STD-45662;MIL-STD- 45208"/> <TR><TD>Location</TD><TD COLSPAN=2>Phoenix, AZ, 21631 North 3rd. Ave, 85027</TD></TR> <UC_ID name="Location" value="Phoenix, AZ, 21631 North 3rd. Ave, 85027"/> <TR><TD>Price Quote</TD><TD>Job Tailored Quotes</TD> <TD></TD> <TD></TD> <UC_FEAT name="Price Quote" value="Job Tailored Quotes" units="" tolerance=""/> </TR> <TR><TD>Process Name</TD><TD COLSPAN=2>Milling</TD></TR> <UC_ID name="Process Name" value="Milling"/> <TR><TD ALIGN=CENTER COLSPAN=4 BGCOLOR=#80FFFF><B>Item Specific Information</B></TD></TR> <TR><TD>Width Capability</TD><TD>.25:175</TD> <TD>in</TD> <TD></TD> <UC_PAR name="Width Capability" value=".25:175" units="in" tolerance=""/> </TR> <TR><TD>Material</TD><TD COLSPAN=2>Aluminum;Titanium;Stainless Steel;Plastic;Inconel;Hastelloy;Beryllium Copper;other specialty metals</TD></TR> <UC_FEAT name="Material" value="Aluminum;Titanium;Stainless Steel;Plastic;Inconel;Hastelloy;Beryllium Copper;other specialty metals"/> <TR><TD>Machine Type</TD><TD COLSPAN=2>CAD/CAM 3D generated CNC</TD></TR> <UC_FEAT name="Machine Type" value="CAD/CAM 3D generated CNC"/> <TR><TD>Related Processes Available</TD><TD COLSPAN=2>CAD/CAM 3D generated CNC Drilling;CAD/CAM 3D generated CNC Turning;Sheet Metal Fab;Welding </TD></TR> <UC_FEAT name="Related Processes Available" value="CAD/CAM 3D generated CNC Drilling;CAD/CAM 3D generated CNC Turning;Sheet Metal Fab;Welding "/> <TR><TD>Technical Support</TD><TD COLSPAN=2>Engineers;Programmers;Operators</TD></TR> <UC_FEAT name="Technical Support" value="Engineers;Programmers;Operators"/> <TR><TD>Computer Aided Support Tools</TD><TD COLSPAN=2>Solid Works;Tek-Soft Pro CAD/CAM</TD></TR> <UC_FEAT name="Computer Aided Support Tools" value="Solid Works;Tek-Soft Pro CAD/CAM"/> <TR><TD>Length Capability</TD><TD>.5:310</TD> <TD>in</TD> <TD></TD> ><UC_PAR name="Length Capability" value=".5:310" units="in" tolerance=""/> </TR> <TR><TD>Metrology</TD><TD COLSPAN=2>CORDAX 1808 Coordinate Measuring Machine; Complete inventory of precision inspection and testing equipment</TD></TR> <UC_FEAT name="Metrology" value="CORDAX 1808 Coordinate Measuring Machine; Complete inventory of precision inspection and testing equipment"/> <TR><TD>Delivery</TD><TD COLSPAN=2>Specified Window;Just In Time;Split</TD></TR> <UC_FEAT name="Delivery" value="Specified Window;Just In Time;Split"/> <TR><TD>Height Capability</TD><TD>.1:31.3</TD> <TD>in</TD> <TD></TD> <UC_PAR name="Height Capability" value=".1:31.3" units="in" tolerance=""/> </TR> <TR><TD ALIGN=CENTER COLSPAN=4 BGCOLOR=#00FFFF><B>Additional Attributes</B></TD></TR> </TABLE><p> </UC_ENTRY></UC><BR><BR></BODY></HTML>
