|
[XML-DEV Mailing List Archive Home] [By Thread] [By Date] [Recent Entries] [Reply To This Message] RE: XLink transformations
It is and I've said before that the issue with hyperlinking back to the Hytime drafts was not being able to tell if a behavior is associated with a hyperlink. We had some *contentious* debates in the XML interest group over this. We know by observation an <a href="" goes somewhere, but without the implementation, we don't know how. The user doesn't always need to know, but the author does, so hyperlinks and address resolution are intertwined as a practical matter no matter whose implementation or theory is invoked. We sprinkle the "fairy dust of objects" because as magic goes, it produces repeatable results. There are other kinds of magic. "Where do you want to go today?" but the repeatability is at issue. As time goes on, I'm not convinced the case for hyperlinks is worse than the case for any markup element: is it 1. A data object. A structure (say, struct) with declared data (see Horowitz and Sanhni: Fundamentals of Data Structures). Implementation independent but unreliable. 2. A class. Includes the methods. Reliable but implementation dependent. 3. Neither or both depending on context. This is the "choose the form of the Destructor" problem. Careful what pops into your head because the results may be "sticky". In HyTime, the answer was that the best one could do was abstract the types of hyperlinks depending on the type of addressing and that dependent on the context of the location. In that sense, it is a data object. However, on the bold move to XML, a lot of otherwise reasonable people became convinced that elements are classes and that made the JavaHeads happy. It is unfortunately, not of necessity true but it is in practicality, useful. IMO: Read the contracts. If the element contract is only declaring a relationship, it is a data object. If it declares a means or description of its resolution (the semantic), it is a class. Note that without such *contentious* specs such as HTML Components, it is pretty difficult to build over this reliably and reusably. To quote Dr Goldfarb, "eventually, somewhere a bit must change state". HTCs and binary components do provide a means to build and are simple enough to teach to the less well-trained. I like them for practical reasons but I understand the problems of univerality of asp:myThing namespace. On the other hand, schedules and budgets delimit results. There is only so far declarative systems get one before a function is needed and at that point, the reliability of interoperation becomes statistical. Len Bullard Intergraph Public Safety clbullar@i... http://fly.hiwaay.net/~cbullard/lensongs.ram Ekam sat.h, Vipraah bahudhaa vadanti. Daamyata. Datta. Dayadhvam.h -----Original Message----- From: Simon St.Laurent [mailto:simonstl@s...] Hyperlinking has always been something of a hydra, and I'm afraid that the delays on XLink have left it a sleepy hydra. On the other hand, the spec's a lot better than it was....
|
PURCHASE STYLUS STUDIO ONLINE TODAY!Purchasing Stylus Studio from our online shop is Easy, Secure and Value Priced! Download The World's Best XML IDE!Accelerate XML development with our award-winning XML IDE - Download a free trial today! Subscribe in XML format
|
|||||||||

Cart








