Subject: Re: Data misuse (was Re: template matching..) From: Sara Mitchell <smitchel@xxxxxxxxxx> Date: Mon, 29 Mar 1999 09:45:40 -0800 |
Well, from my perspective, what you are talking about is DTD documentation and versioning. The groups that control current industry-specific DTDs in the SGML community do this -- both in comments within the DTD and in separate documentation that can be delivered in many formats. In some ways, it's very much like documenting an API, you're responsible for letting your user community know about changes, especially if a change makes something backward incompatible. It also makes it clear that versioning needs to be considered as you design your DTDs. You can include version numbers in the PUBLIC ID for the DTD. Unfortunately, with XML, there is no requirement for a processor to pay attention to the public ID, but it could also be done in the namespace. This could be used as a signal on the client-end that the data they are receiving may use a different standard than their current stylesheet. I know all of this sounds awkward, and you're undoubtedly right that more specific and efficient methods need to be worked out. So we have more to work on, right? Marcus Carr wrote: > > Guy_Murphy@xxxxxxxxxx wrote: > > > You're right in that there is a relationship between the data provider and > > the data reciever. I would however say that in business terms a large part > > of this relationship is still best solved person to person in that we > > provide *very* large data feeds to companies, and any changes to those > > feeds would be part of a negotiated business solution. > > Yes, in a large and formal situation this would certainly cease to be an issue. > > > Likewise I as a developer of Web applications now recieve data from the > > back-end in XML format. This solution was negotiated between myself and the > > back-end developers. Likewise any change would be negotiated. > > Yes, provided that the back-end developers know that you exist, know that you > have some reliance on their data in its current structure and care about your > reliance enough to override their original reason for change. > > > All this doesn't change the fact that in the end it is my resopsibility as > > the recipient of your data to deal with that data. Obviously if you can > > facilitate that the relationship will be a happier one, but I certianly > > don't like the experience of the data provider dictating the stylesheet. > > I can see both sides of the coin - but I still believe that given enough rope, > some users will hang themselves. I suspect that this is just another of the > many side effects that XML is bringing; with anything worthwhile and complex > there have got to be some sticking points. I'm curious as to whether anyone has > any thoughts about formalising the relationship between provider and user - any > ideas? > > -- > Regards, > > Marcus Carr email: mrc@xxxxxxxxxxxxxx > ___________________________________________________________________ > Allette Systems (Australia) www: http://www.allette.com.au > ___________________________________________________________________ > "Everything should be made as simple as possible, but not simpler." > - Einstein > > XSL-List info and archive: http://www.mulberrytech.com/xsl/xsl-list XSL-List info and archive: http://www.mulberrytech.com/xsl/xsl-list
Current Thread |
---|
|
<- Previous | Index | Next -> |
---|---|---|
Re: Data misuse (was Re: template m, Marcus Carr | Thread | Re: Data misuse (was Re: template m, Marcus Carr |
XSL to Plain text Formatter, Gerard Berthet | Date | RE: XML on Gecko, Didier PH Martin |
Month |