RE: [xml-dev] re: IDs and databases (Was: determining ID-ness in XML)

["Champion, Mike" <Mike.Champion@SoftwareAG-USA.com>]

> -----Original Message-----
> From: Jeff Greif [mailto:jgreif@alumni.princeton.edu]
> Sent: Wednesday, November 07, 2001 12:47 PM
> To: Champion, Mike; xml-dev@lists.xml.org
> Subject: Re: [xml-dev]  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!).