[XML-SIG] XLink support from Python?
Mon, 10 May 1999 02:08:22 -0500
> We have some basic XLink functionality in Python that we use in-house. We
> were planning to dust it up a bit and let people use it, but then the freight
> train (benign, in this case) known as the latest XSL working draft came
> along... Still, the basics that we have are enough to allow us
> write/manipulate XML with basic "embed" and "replace" links.
The "embed" and "replace" junk in XLink is incredibly underspecified and I
think that it is pretty dangerous to interpret them. For instance,
according to what justification do you treat a link to an XML element
differently from a link to a PDF document (or do you have a model that
also allows those to be embedded). It seems to me that "embed", "replace"
et. al. are behavioral junk for browsers -- no more, no less. You should
treat an "embed" of an XML element as you would an embed of a JPEG -- the
XLink spec. does.
You would be better off adopting a local convention that has exactly the
right semantics you need. Call it UCHE:transclude. I started writing a W3C
NOTE for such a convention (hope you don't mind me using your name) but I
realized that I really needed a more robust data model than that provided
by the XML family of standards so I started working on that data model
instead. The tricky part that made me start thinking about the data model
is how do you express hyperlinks from one part of the logical document to
another? You need to extend the concept of URL to allow references to
abstract objects that result from transformations (like the transclusion
transformation). That means that you need a concept of abstract
objects...which is what XML has been lacking since day 1 (despite my
Paul Prescod - ISOGEN Consulting Engineer speaking for only himself
The first three Noble Truths of Python:
All that is not Python is suffering.
The origin of suffering lies in the use of not-Python.
The cessation of suffering can be achieved by not using not-Python.