[
Lists Home |
Date Index |
Thread Index
]
Simon St.Laurent wrote:
.
>
> Text in general seems much better at ambiguity than at specificity.
> Markup structures help, but I'm not particularly convinced that they
> help that much. Defining canonical lexical representations (and
> transformations that avoid inflicting them on humans) seems like a
> better route around this than defining types.
>
The point I am trying to make is that the apparently common notion of
programming language "types" is a subset of a more general notion of "types"
as classes of things.
Take the phrase: "canonical lexical representation" do you mean an
"archetypical lexical representation"?, not quite but the term "canonical"
implies that there exist a _set_ of equivalent lexical representations. The
notion of a "canonical lexical representation" itself implies a _set_ of
lexical representations all representing the same thing. One can consider
the canonical representation an archetype from which alternate or synonymous
lexical representations are derived.
In the case of XML in specific, or markup in general, the _things_ that we
are concerned with are documents, elements and attributes. In an entirely
lexical fashion we can define the set of XML elements as having a start tag,
content and an end tag, the start and end tags being constrained to have the
same name.
XML 1.0 talks of document types, element types and attribute types. The
element _name_ specifies its type. This sort of type has nothing to do with
binary integers, floats etc. and everything to do that an element type or
name is simple the set of all elements whose start and end tags have the
given name.
The element name is a property of the element which defines its type. That
is to say the set of all elements of a given type is a subset of all
elements, constrained to those whose tag name is the particular element
type. To me, this is the essence of markup, a way to distinguish and direct
processing of particular parts of a document.
In any case the _types_ I am discussing are a perfectly reasonable way to
_lexically_ describe what markup is and why markup is useful.
Jonathan
|
