[
Lists Home |
Date Index |
Thread Index
]
"W. E. Perry" <wperry@fiduciary.com> wrote:
| As a poetics of vocabulary application and control it is comprehensive,
| elegant and efficient--
Well, there are some details I left out, but yes, comprehensiveness is
easy here. Elegance, I would think, flows from the protean simplicity of
the attribute mechanism - the name of the attribute dedicated to denoting
a semantic association, and the value to carry a referent instantiation -
especially when the referent is information of an externally fixed form
(such as a predefined name!).
Efficiency is a different matter though. Everyone rightly quails at the
prospect of verbose markup. So, there's room to devise defaulting schemes
("scoping" is just a fancy word for minimization) at the cost of extra
processing overhead in the parser-level module supporting all this, but
there's no getting around the fact that at the level of "primitive"
discrimination operations, something is being "said" at each start-tag.
I might add that the principal difference between the schematic outlined
here and classical ArchForms is the lack of any dependency on schema
information. The defaulting scheme in AFs, for instance, relies on schema
driven parsing ("auto-recognition of architectural names and content"),
besides of course requiring the original document to be itself valid
comprehensively with respect to some DTD. This is an unnecessarily strong
coupling of vocabulary combination (which *can* be done through instance
markup alone) with schema combination (which *is* a much harder problem.)
| though it is not immediately concerned with ease of programmer's access
| to the manipulation of XML
Filters can be built on something as simple as SAX1. First, all names are
atomic strings - no slicing and dicing. Second, support will be needed
for tokenization of control strings to get the mappings into usable form.
Third, the difference between this and SAX2-style namespace processing
will probably take the form of associating a namespace constant (the
"name" of the vocabulary itself) with *groups* of names - corresponding to
the relevants set of GI+attributes reconstituted into vocabulary specific
form - rather than individual names. Sort of like viewing each element as
having potentially multiple interpretation contexts.
And believe it or not, for generic or formal organizational purposes such
as these, we could actually put colons to use, taking advantage of the
far-sighted move to include it in XML as a name-start character. For
instance, we could require conventionally that all control attributes have
names starting with a colon, to indicate that they have significance for
*parsing* only, and are not part of the semantic freight for any of the
relvant vocabularies in the document.
(And as a side note, we might consider the use of just ':' by itself as
the conventionl name of the ID attribute!)
|
