RE: Options for dealing with IDs

From: Chris Lilley [mailto:chris@w3.org]

>I agree that in some cases, particularly local filesystem processing,
>DTD validation gives trivial overhead.

Accepted. I do wish we had numbers to illustrate the 
overhead otherwise.

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

>Except that, for those people who assert that well formed documents
>can have no IDs, the fact that SOAP needs IDs can be seen as
>triggering that demand.

Sure and not to restart the discussion, someone could always 
reply, "so validate" and someone says "They just won't do it" 
and that might not be a good enough answer if the press or 
the developers are not satisfied.  One problem is factoring decisions 
made by language designer post hoc given the previous 
decisions of the metalanguage designers without rationale 
other than "it makes languageX harder" or "languageX decided 
therefore we must amend".  Did the SOAP designers make a
loud demand at the time of the SOAP design about IDs and 
we are just getting a round tuit?  I can understand it in 
this case given the way XML was created, but I hope there 
aren't a lot of these out there given it can raise the 
dickens in the core.  With the evergrowing number of 
systems relying on XML, instability in the core could 
be expensive.

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

>Thank you for that.

Thanks for explaining it clearly and in the face 
of noise.

BCLL> I don't think we can go forward with this 
BCLL> without seriously considering what XML SW 
BCLL> has to offer.   But be warned; this is not 
BCLL> a way to get less conformance levels.  We 
BCLL> will have more.

>We may have more at first, in the same way that namespaces and
>xml:base both doubled the number of conformance levels for (the family
>of xml standards) but things that prove themselves over time can be
>rolled into the core, which takes the number of conformance levels
>down in the same way that after XML 1.1 has been in use for a while,
>an XML 1.0 processor that enforces disallowing Unicode characters
>post-2.0 will be just not useful and the number of conformance levels
>will decrease again, 1.1 replacing 1.0.

It's the backward compatibility problems that worry me, but that 
is just another day in dllHell.

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

>I think this is the time, because we are starting to get
>muti-namespace documents shipped around and the problems are becoming
>unmanageable.

Anyone made a list of those problems with examples drawn 
from existing systems?  I don't doubt they exist, just that 
when the press starts in, a concise set of examples for them 
to clone is useful.  Maybe everyone who is asking for this 
should also be asked to submit their favorite example from 
their own system.

len

Received on Friday, 10 January 2003 13:40:52 UTC