Cart
[Home] [By Thread] [By Date] [Recent Entries]
> -----Original Message----- > From: Jeff Greif [mailto:jgreif@a...] > Sent: Wednesday, November 07, 2001 12:47 PM > To: Champion, Mike; xml-dev@l... > Subject: Re: re: IDs and databases (Was: > determining ID-ness > in XML) > > > Why couldn't the DB return the retrieved subtree with ino:id > defined as an ID attribute in an internal subset part of the returned > document This could break the author's validation schema ... and since not all client-side tools understand DTDs, especially internal subsets, it's probably going to hurt more end-users than help. > Why would we need a new mechanism where the DB > would stick in a PI that the app would have to know about? We don't "need" anything; this is a convenience feature, and the DB use case is just one that I'm personally familiar with. It just seems to me (personally, usual disclaimer, blah blah) that a widely acception convention for declaring id-ness with a PI or namespace would be a nice thing. If the app doesn't know about the PI/namespace, it quietly ignores it. DB's could stick it in to "declare" their ID attributes as IDs, DOM/XSLT implementations could recognize that convention and use it, and users can exploit it or not. This use case brings up a couple of questions: - *Can* some middleware stick in an id-ness declaration without breaking the id-ness declaration of the author? Would allowing multiple idatts fix this, or just make it harder for the DOM/XPath/XLink to figure out which id attribute was being matched on? - I REALLy hate to say it, but if middleware puts in some sort of namespace prefixed id-ness declaration, it could break DTD validation since the validator wouldn't know to ignore the prefixed attributes in another namespace. Doesn't this argue for declaring id-ness with PIs? That really is the tried and true way of sticking in pseudo-attributes that can be used by applications without breaking validation. For example, Arbortext Adept/Epic uses a PI to tell itself the current cursor position the next time it opens a document. Other processors may ignore the PI or throw it away; in either case, no harm done (worst case is that Epic opens the doc at the top). They couldn't do this with XML attributes or elements without breaking the validation (or forcing the customer to put vendor-specific junk in their DTDs). Likewise, untold generations of applications developers would put their metadata (e.g., information used to generate some UI component on the fly) in a document as PI pseudo-attributes. I can kinda sorta see how this could be done with namespaces, but it's exactly what PIs were invented to do. (Somebody please convince me otherwise; I would like to see PIs put to sleep as much as anyone!).
|
