Re: Options for dealing with IDs

Tim Bray writes:

> Bullard, Claude L (Len) wrote:
> > Someone please explain why this isn't a realistic 
> > option given an on-demand scenario.  If the DTD/Schema 
> > were ALWAYS processed, I agree that is a bad thing.
> > The one thing that jumps out at me is that requiring 
> > a DTD or Schema just to get at ID declarations is 
> > a heavy requirement given that the number of 
> > applications that use IDs is large, so this 
> > can in fact, become a virtual requirement to 
> > always get the DTD/Schema.
> > 
> > Is that it? 
> Pretty well.  I lot of apps are just *not* gonna do it; but they still 
> might like to know about IDs. -Tim

I'm in complete agreement with Tim.  SOAP is an example of a system that 
uses xsd:ID [1] typed attributes and which goes to some lengths to NOT 
>require< validation of any sort, though partial or full validation of the 
message is permitted if useful to the consuming application. [2,3]. SOAP's 
ID attributes are in its own namespace. 

IMO, DTD or schema retrieval, as well as validation, is often impractical 
for performance and security reasons, among others.  Interestingly, among 
the many performance risks we analysed in the schema WG were reports from 
implementors that failures to retrieve (timeouts) had bigger performance 
impact than successes.  Furthermore, tf validation is required, then the 
document becomes useless in the case where an external DTD or schema is 
for some reason unavailable.  I think this is unacceptable. 

I think I agree with Tim's other conclusion:  do nothing is probably the 
least risky solution.  We've got too many typing mechanisms already.



Noah Mendelsohn                              Voice: 1-617-693-4036
IBM Corporation                                Fax: 1-617-693-8676
One Rogers Street
Cambridge, MA 02142

Received on Thursday, 9 January 2003 15:17:57 UTC