RE: Options for dealing with IDs

That's ok but a little over the top because it 
is easy to construe it as DTD/Schemas always 
hurt performance and should be avoided.  That would 
be unacceptable as well.  I don't think that is 
what you mean.

SOAP is engineered to ensure a DTD or Schema is 
never needed.  No demand.  That's good.  A more 
complex document with more opportunities for errors 
can create demand and it should be met with consistent, 
easy to apply features for validation.

Otherwise, Goldfarb's fear that message oriented 
XML requirements will overwhelm document oriented 
XML requirements will become reality.  The result 
would be abandoning XML for document technologies.

That is a bad outcome.

I'm not convinced we can do nothing.  The position 
that some metainformation needs to be conveyed by 
simpler means, eg, that small set of decorations 
an XML processor needs to do ubiquitous tasks, 
is compelling.  The XML namespace is the right 
place to do it.  The DTD/Schema are the wrong 
place I am finally convinced. :-)

When we did XML 1.0, we were in a chopshop mode 
of operations.  That is not an insult; it was 
speed to market in a time when the survival of 
generalized markup was in doubt.  We now have 
the time to reconsider at leisure, the parts 
we stacked over in the corner.

I don't think we can go forward with this 
without seriously considering what XML SW 
has to offer.   But be warned; this is not 
a way to get less conformance levels.  We 
will have more.  That may be ok.  In SGML 
in the mid nineties, we talked about the 
Unicorn tests because it was self-evident 
that we lacked precisely this kind of 
modularization in SGML.  It worked for the 
authors but the implementations were too 
expensive and too rare.  The same thing 
happened in VRML97/2.0.  So modularization 
per se doesn't bother me.  Divesting a class 
of users of the tools they need would.

If this isn't the time, ok.  If it is, then 
we have the time this time to do it right.

len


From: noah_mendelsohn@us.ibm.com [mailto:noah_mendelsohn@us.ibm.com]

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.

Received on Thursday, 9 January 2003 15:37:02 UTC