XLink: behavior must go!
Oren Ben-Kiki wrote: >you can use an industry-standard DTD to good effect - it is just that the industry in question isn't "the XML industry"; instead it might be "the XML browsing industry", and the standard isn't "XML", it is "XML as used in browsers". There's simply no way a browser will be able to correctly handle links whose behavior is specific to vlsi design process, unless someone explicitly codes a stylesheet which explains how to do so. The problem I am trying to deal with is not related to "the XML industry" or "the XML browser industry" - instead it relates to a set of DTDs that share common-features which apply to a wide range of applications shared by a wide range of industries. If we are to develop sharable toolsets we need to develop sharable architectures. The key point is that I want, in the longer term, to replace the current practice of relentlessly copying data from one message to another (up to 10 times in some processes) with a process that allows linking to the original source of the data. The way this will be done will depend on the type of the data being linked to and on the local conditions for access to original documents. OK, I can define a generalized architecture that would be widely used for this purpose, and call it edi:behaviour, but as this is widely required by others why not also have it as a standard mechanism for passing link instance dependent information to the link processor? It should not be necessary to have individual stylesheets for individual instances of messages. It should not be necessary to redefine processes for each DTD that uses the shared information. We need to import standardized modules that will process standardized namespaces of elements in ways that depend on the conditions applying at the point at which the located data is to be retrieved from. Paul Prescod wrote: >So you want the features of the whole grove model and API and you think that a single standardized attribute name is going to give it to you? I have given up hope of getting an extensible grove model (note the key word at the beginning) or a proper API for managing the associations between XSLT and XML document instances (note that it is the instance I worry about, not its formal model). This is why I want to introduce, as a stop gap, a single architectural form that will apply to one class of objects in which I know from experience there is a particular problem. I would dearly love a better thought-out, long term solution based on proper architectural form definition, but in the meantime need to retain the stop-gap attribute to manage link processing. Don't throw out the bathwater until you know you have something to give the baby to drink. [They have just announced that they have cut the water supply to my house, which made me think of this variant of the metaphor!] Martin Bryan xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@i... Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ and on CD-ROM/ISBN 981-02-3594-1 To (un)subscribe, mailto:majordomo@i... the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@i... the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@i...)
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