[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
RE: SVG paths in XSLT (was: Using W3C Regular Expressions)
- From: "Bullard, Claude L (Len)" <email@example.com>
- To: firstname.lastname@example.org, Robin Berjon <email@example.com>
- Date: Fri, 20 Apr 2001 09:17:56 -0500
This points out something that recurs a lot and
was noted often in the days before people were
trained to think of markup languages as a single
DTD or schema which everyone implements: the
need for an up/down transformable language spec.
This approach was well-understood and documented
in the past.
For a standard language there should be:
1. A form that is an up translation target. The
maximum information form into which and out of
which other forms can be created.
2. Specifications for compressed format. These
should be normatively expressed as the transform
In the SVG example, Henry's preferred form is
the up form. It is not terse, but it can be
used for lossless description. SVG with
minimized paths is a compressed form, one
of the possible normative compressed forms
which could be documented by transform.
The idea of identity equivalence should
be relaxed to similarity by pattern where
a pattern represents the ability to create
a similar form. Similarity does not infer
isomorphic identity, only that the category
or class can include its non-reversible
forms as family members.
It seems trivial, but has implications for
how we take specifications for languages
and adopt them into flexible standards.
It changes our thinking from one of
colonization and policy laundering to
standardization the accepts the potential
for family variants related by standard
and normative transforms.
Intergraph Public Safety
Ekam sat.h, Vipraah bahudhaa vadanti.
Daamyata. Datta. Dayadhvam.h
From: firstname.lastname@example.org [mailto:email@example.com]
I wanted to be able to go _the other way_, and without
_deeply_ tedious us of string functions and so in in XSLT I can't.
I agree that in principle the move we want to encourage is _out of_
other formats _into_ SVG, as you've done, but sometimes the other way
is necessary, and the actual application I had in mind was for
tutorial _display_ of SVG paths, i.e. SVG->HTML.