|
The SCHEMA link gives the URL of a document describing the scheme used to assign
metadata to the current document. Origin: Dublin Core. E.g.
<META NAME="VW96.objecttype" CONTENT="Dictionary">
<LINK REL = SCHEMA.VW96 HREF="http://vancouver-webpages.com/VWbot/VW96-schema.html">
Note: This example is from an older version of the Dublin Core draft.
Schema
The Schema tab allows access to defined data schemas or custom sets of meta tag
information that can be inserted into a web page.
Meta Tag Maker comes with the following sets:
WAGILS
AGLS
BASE
Dublin Core
GILS
IMS
MS Extended
PUBLISH
A-CORE
Michelin
To utilize a given set, select it from the drop down selection
box.
If you wish to make a meta tag schema the default for the open
web site then click Set As Default.
Enter the information required by each meta tag name. Only
those tags that are not left blank will be written to the page.
Default Values
If a page already contains a meta tag schema, the schema selection will be set
to the type used by the page. Each defined tag of the schema contained on the
page will have it's value shown in the meta tag table.
Removing Tags
If you wish to remove a set of tags, check Remove Tags. When Generate is clicked
the selected schemas tags will be removed.
Defining New Schemas
Schemas are text files keep under the installation directory in a folder
called "schemas". The file schema.txt lists each schema that should be displayed
by the selection box. The list entry is just the name of the file minus the file
extension of .tgs. Please note the last entry may not contain a return. It must
end the file.
Each schema .tgs file defines the meta tags that are associated
with a given schema. The file is formatted as follows using the Michelin schema
as an example:
| 2,5,-1 |
Number of columns, Number of Meta Tags to be defined |
| 1930,Meta Tag Name |
Column 1 size in pixels, Column Name |
| 3130,Meta Tag Value |
Column 2 size in pixels, Column Name |
| 0,1,Creator,0 |
Column number, Meta Tag Number, Tag Name,Must Be Zero
(MBZ) |
| 1,1, ,0, |
Column number,Meta Tag Number, Default Tag Value,Length
(0 = no limit), Input mask |
| 0,2,Creation Date,0 |
Column number, Meta Tag Number, Tag Name,Must Be Zero
(MBZ) |
| 1,2, ,8,99/99/99 |
Column number,Meta Tag Number, Default Tag Value,Length
(0 = no limit), Input mask |
| 0,3,Expiration Date,0 |
Column number, Meta Tag Number, Tag Name,Must Be Zero
(MBZ) |
| 1,3, ,8,99/99/99 |
Column number,Meta Tag Number, Default Tag Value,Length
(0 = no limit), Input mask |
| 0,4,Classification,0 |
Column number, Meta Tag Number, Tag Name,Must Be Zero
(MBZ) |
| 1,4, ,0, |
Column number,Meta Tag Number, Default Tag Value,Length
(0 = no limit), Input mask |
The last entry in the .tgs file must not end with a carriage
return.
Defining Input Masks
The input mask must be a string composed of the following symbols:
1) Wildcards
0 digit
9 digit or space
# digit or sign
L letter
? letter or space
A letter or digit
a letter, digit, or space
& any character
2) Localized characters
. localized decimal separator
, localized thousand separator
: localized time separator
/ localized date separator
3) Command characters
\ next character is taken as a literal (not a special character)
> translate letters to uppercase
< translate letters to lowercase
; group delimiter (see below)
The group delimiter character is used to control additional options. If present
in the mask string, then the part of the mask to the left of the first delimiter
is used as the actual mask. The part to the right is interpreted in this way:
1) If a lowercase 'q' is present, the control edits in 'quiet' mode (no beeps on
invalid characters),
2) The last character is used as a placeholder (instead of the default
underscore).
For example:
Set the mask so the user can enter a phone number, with optional area code, and
a state in capitals. This will beep on invalid keys.
(###) 000-0000 St\ate\: >LL
Similar mask, but in quiet mode (no beep for wrong keys) and with an asterisk
instead of underscore for a placeholder:
(###) 000-0000 St\ate\: >LL;q;*
Here are some more commented examples:
EditMask String Description
"St\ate\; >LL" Is a valid format. The 'a' and ';' characters are escaped and
thus taken as literals. The '>' is used to ensure that the next two characters
will be represented in uppercase.
"St\ate\; >LL;q;*" Is a valid format. It is similar to the previous example, but
the 'q' after the delimiter puts the control in quiet mode. An asterisk '*' is
used as placeholder instead of the underscore, because that is the last
character after the delimiter.
"St; >LL" This is an invalid format. The mask itself is just "St" (the part to
the left of the ';' delimiter. There are no wildcards, so the user can't type
anything. If he could, the placeholder character would be "L" (last character
after the ';' delimiter).
"; >LL" This is an invalid format. The first character is a delimiter, so there
is no real mask at all.
The XML Schema Specification in Context
Rick Jelliffe
Academia Sinica Computing Centre
2000-02-24 draft only
This note gives simple comparisons between XML Schemas and the technologies
that have influenced it. It does not provide an exhaustive list of all XML
Schemas features.
1. XML Schemas and XML Instance Markup
XML Schemas does not defined on markup but on the parsed information set of a
document, for example as made available by the W3C DOM API. Thus entity
derefencing and attribute defaulting from any XML markup declarations will
already have taken place, as informed by the standalone parameter of the XML
Header, when a document is parsed.
| XML Instance Markup |
XML Schema |
Comments |
| Element |
XML Schemas can constrain which
elements are allowed in a particular context. |
|
| Attribute |
XML Schemas can constrain which
attributes are allowed in a particular context. |
|
| xml:lang global attribute |
No specific support. |
A special datatype for language is
available. However, there is no facility for global declarations. |
| xml:space Global Attribute |
No specific support |
There is no facility for global
declarations. There only facility for specifying which whitespace should
be ignored is that an element type can be declared "rich" or
"elementOnly". |
| Attribute Value |
XML Schemas can constrain which
attribute values are allowed in a particular context. |
|
| Data Content |
XML Schemas can constrain which
attribute values are allowed in a particular context. |
|
| CDATA Sections |
No support. |
|
| Comments |
No support |
|
| Processing Instructions |
Supported through NOTATION |
|
| Entity References |
No support |
|
| Character Reference |
No support |
|
XML Header
(uses PI tagging conventions) |
No support |
An XML Schema can/cannot used with any
version of XML 1.n. ?? xml:standalone=no does/does_not affect XML
Schemas.
The encoding declaration is not part of the core information set of an
entity, consequently there is no support for contraining it in XML
Schemas. |
Namespace
(uses attribute tagging conventions) |
No spcial support for declarations |
XML Schemas uses namespaces |
2. XML Schemas and XML Markup Declarations (XML DTDs)
XML Schemas provides mechanisms for declaring, defining and refining data
types. The datatypes can be used equally on attribute values or element #PCDATA
values. XML Schemas, in contrast, provides NOTATION, a way to declare data types
of elements but not to define them nor the primitive types to derive other types
from. XML Markup Declarations are only geared to provide simple support for
creating graph-structures, rather than for allowing data-typing of data.
| XML Markup Declarations |
XML Schema |
Comments |
| DOCTYPE Declaration |
No equivalent header declaration. |
An XML Schema cannot specify which is
the top-level element in any schema. The attribute schemaLocation can be
used on elements in instances to nominate the location of a retrievable
schema for that element associated with that namespace. |
| Internal and External Subset |
No equivalent header declaration.
There is no mechanism for over-riding a declaration. (A SchemeSet
element has been mooted to gather seperate schema elements together.) |
A schema for a single namespace can be
composed from several distriubuted schema documents. Furthermore,
instance may require reference to multiple schemas as it uses elements
from different namespaces. A Schema can be composed of several entities;
the <import> and <include> mechanisms are also available. |
| ELEMENT Declaration |
An <element> declaration creates a
binding between a (namespaced) name and attributes, content models and
annotations. |
The big difference between XML DTDs
and XML Schemas is the tag/type distinction. |
| #PCDATA Declared Content Type |
Supported as particle of simple |
|
| ANY Declared Content Type |
Supported as <any> |
<any> has different wildcards, to
support a richer range of possibilities. Note that <anyAttribute> is
also available to allow wildcards on the possible attributes. |
| EMPTY Declared Content Type |
Supported |
Note that XML Schemas supports an
explicit null, as distinct from empty strings. In XML and SGML an
implied attribute with no default can be taken as having a null value
(actually, the value is to be implied by the application or processor)
but this was not available for elements. |
| Content Model |
Supported as <complexType>. |
XML Schemas keeps the XML Markup
Declarations requirement for unambigous content models. Note that XML
Schemas maintains XML's model of mixed content, either allowing
character data anywhere inside an element or nowhere. |
| , (Sequence Connector) |
Supported. Sequence compositor |
|
| | (Alternative Connector) |
Supported. Disjunction compositor |
|
| ? (Optional) |
Supported, through maxoccurs and
minoccurs attributes |
|
| + (Required and Repeatable) |
Supported, through maxoccurs and
minoccurs attributes |
|
| * (Optional and Repeatable) |
Supported, through maxoccurs and
minoccurs attributes |
|
| ( ) (Groups) |
Supported |
|
| ATTLIST Declaration |
<attribute> declarations can be
grouped into <attributeGroup> declarations. |
|
| Multiple ATTLIST declarations |
Not supported |
(Do equivalence classes do something
similar?) |
| CDATA Attribute Type |
Supported as a built-in simple type
"string" |
Lexical constraints can be specified
using regular expressions. |
| ID Attribute Type |
Supported as a built-in simple type.
The Key mechanism represents a major enhancement. |
Lexical constraints on these names can
be specified using regular expressions. |
| IDREF IDREFS Attribute Types |
Supported as a built-in simple type.
The Key mechanism represents a major enhancement. |
Lexical constraints on these names can
be specified using regular expressions. |
| NOTATION Attribute Type |
Supported as a built-in simple type. |
Lexical constraints on these names can
be specified using regular expressions. |
| NMTOKEN NMTOKENS Attribute Types |
Supported as a built-in simple type. |
Lexical constraints on these names can
be specified using regular expressions. |
| ENTITY ENTITIES Attribute Types |
Supported as a built-in simple type. |
These are a kind of link, with
declarations distinct from reference. Lexical constraints on these names
can be specified using regular expressions. |
| Enumerations |
Supported |
|
| Attribute Defaults |
|
|
| #FIXED Attributes |
|
|
| #REQUIRED and #IMPLIED |
Supported through the minOccurs
attribute |
|
| ENTITY Declaration |
Not supported |
Entities are declared in XML markup
declarations. |
| ENTITY % Parameter Entity Declaration |
Not supported |
Parameter entities provide a low-level
mechanism useful for many different purposes. XML Schemas has tried to
support first-class support for some of the most important:
- * the separation of <element> and <complexType>;
- * attribute groups;
- * named model groups;
- * the type extension and restriction mechanisms;
- * the <import> and <include>
mechanism for composing schemas;
* the element equivalence class mechanism allows redefinition of
element names
Note that general entities can also be used to provide some of the
other rarer uses of parameter entities.
XML Schemas 1.0 does not attempt to systematically reconstruct every
possible use of parameter entities. |
| IGNORE/INCLUDE Marked Sections |
Not supported |
|
| NOTATION Declaration |
Supported as a built-in simple type. |
|
| Comment |
The <documentation> subelement of the
<annotation> element provides this functionality. (Comments can still be
used.) |
<documentation> elements are available
to users of the Schema. Comments are not part of the core information
set of the document and may not be available or in a useful form. |
| PI |
The <appinfo> subelement of the
<annotation> element provids this functionality. (PIs can still be
used.) |
<appinfo> elements are available to
users of the Schema. Pis require knowledge of their notation to parse
correctly. Extensions to the XML Schema can be made using <appinfo>,
however an extension will not change the schema-validity
of the document. |
2.1 Role of XML Markup Declarations in the Immediate Future
XMLMarkup Declarations are not superceded by XML Schema 1.0 and there is no
general way to specify that DTD processing should not occur nor to verify that
it has not. So Markup Declarations will continue to be useful for non-schema
related tasks in the near future, in particular as a simple and terse syntax for
removing document constants to headers: this is not, strictly, a task related to
data- or structural type specification:
- Entity declarations;
- Namespace declarations;
- Global variable defaults, particularly for xml:space;
- Attribute defaulting.
DTDs terseness and widespread deployment in XML processors also makes a
suitable notation for simple client-side validation; an XML Schema may be
transformed into the closest approximating DTD.
XML Schemas 1.0 does not provide any mechanism equivalent to IGNORE/INCLUDE
marked sections. Consequently, if such functionality is required as part of the
markup, DTDs should be used. However, this functionality can be achieved in
other ways, for example be a schema management appplication.
3. XML Schema and SGML Markup Declarations (SGML DTDs)
SGML (ISO IS 8879:1986 as ammended 1997) provides additional features and
capabilities to XML. SGML allows the specification of many different kinds of
grammars: different levels of tag and delimiter ommissibility, contextual
delimiter recognision, and a richer support for modeling a document as an
asynchorous tree of elements and tree of entities, each of which can have local
links and other attributes. Consequently, an SGML DTD is really a grammar
specification rather than a data schema per se,
though it practise a grammar contains enough structural definitions to make it
useful for many kinds of data modeling.
| SGML Markup Declarations |
XML Schemas |
Comments |
| CDATA Declared Content Type |
Not supported by XML |
This is a parser function. |
| RCDATA Declared Content Type |
Not supported by XML. |
This is a parser function. |
| ANY Declared Content Type |
Supported by <any/> |
Various wildcards allow ANY to be
restricted to certain namespaces. Also, equivalence classes allows a
content model to name elements but not specify their content model. Type
derivation allows an content model to specify an element type, but
leaves the particular name to be used by a particular element type free. |
| & Connector |
Conjunction. The <all> element allows
this functionality at the top-level of an element only. |
|
| SGML Content Models |
Does not have an equivalent of
allowing #PCDATA as a particular particle in content models. |
XML Schemas keeps the SGML requirement
for unambiguous content models. The big difference between SGML DTDs and
XML Schemas is the tag/type distinction. |
| Global Inclusion Exceptions |
Not supported directly. A single-level
inclusion can be made by using type-refinement on the complex types
elsewhere. |
However, the effect of a global
inclusion can be achieved by deriving restricted types for each complex
type possible underneath an element, to any level. This may double the
number of declarations. |
| Global Exclusion Exceptions |
Not supported directly. A single-level
exclusion can be made using type refinement. |
However, the effect of a global
exclusion can be achieved by deriving restricted types for each complex
type possible underneath an element, to any level. This may double the
number of declarations. |
| NUTOKEN NUTOKENS, NAME, NAMES
Attribute Types |
Can be supported using regular
expressions |
|
| ENTITY Types (e.g., SDATA, CDATA) and
Data Attributes (Attributes on Entities) |
Not supported |
|
| #CONREF Attrbute Keyword |
Not supported |
No support for keying occurrence from
the value of an attribute. |
| SUBDOC |
Not supported |
However, the key mechanism allows a
scoping of Ids and IDREFs; and both the namespace mechanism and the
tag/type mechanism allow Gis to refer to different type in different
contexts. |
| LINK Attribute Groups |
Not supported |
However, a similar effect can be
gained using type refinement. |
| Data Attributes on Elements |
Not supported |
|
4. XML Schema and SGML Extended Facilities (Meta-DTDs and Lexical Types)
An XML Schema is a high-level specification of an architecture. XML Schemas
could be implemented as:
- a transformation on the document to add xsi:type elements, based on the
type derivation mechanism;
- a transformation on the schema to derive an effective schema, expressed
according to the HyTime Architectural Forms Definion Requirements;
- architectural parse of the document using the effective schema as a
meta-DTD and the xsi:type attribute as the element form.
It has not been proven yet that all XML Schema contraints can be expressed
using meta-DTDs and the other standard features of the SGML Extended Factilities
(given in the Annexes to the ISO HyTime standard). Consequently, an
architectural validation system using meta-DTDs in SGML markup declaration
syntax may not completely validate every XML Schemas. In particular, the use of
namespaces complicates understanding of the transformations required. Certainly
it is doubtful that every schema definable using Architectural Forms has an
equivalent XML Schema. The tag/type distinction is the same as the
element-form/architecture distinction: an abstract element type is a "base"
(architectural) element.
XML Schemas provides similar lexical capabilities to the SGML Extended
Facilities Lexical Definition Requirements, using a non-standard regular
expression syntax.
5. XML Schema and Perl Regular Expressions
| Perl Regular Expressions |
XML Schema Regular Expressions |
Comments |
| ^ = beginning of string |
^ = character ^ only |
All regular expression matches start
from the beginning of the string. For substring matching use .*substring.* |
| $ = end of string |
$ = character $ only |
All regular expression matches end at
the end of the string |
| Zero-width assertions, lookahead and
lookbehind, backreferences |
Not available |
|
| Non-greedy + and * |
Not available |
|
| \c |
An XML NAME character |
|
| \i |
An XML initial NAME (i.e, SGML
NAMESTRT) character |
|
| \033 and \xAB |
XML Numeric Character Reference must
be used |
|
| \p{} |
\p{} |
The character classes allowed are the
Unicode Consortium's character classes. |
| schema.NCGILS |
Required. Non-Repeatable |
This element defines the metatags and resides in the correct format in the
template on the Web form for creating HTML metatags. No additional information
is needed. Do not delete this element prior to uploading.
Syntax: <META NAME="schema.NCGILS">
| schema.NCGILS |
Required. Non-Repeatable |
This element defines the metatags and resides in the correct format
in the template on the Web form for creating HTML metatags. No
additional information is needed. Do not delete this element prior to
uploading.
Syntax: <META NAME="schema.NCGILS">
Date: 09/18/05 09:44:39
Subject:
![]()
![]()
| schema.NCGILS |
Required. Non-Repeatable |
This element defines the metatags and resides in the correct
format in the template on the Web form for creating HTML metatags.
No additional information is needed. Do not delete this element
prior to uploading.
Syntax: <META NAME="schema.NCGILS">
|