Re: Options for dealing with IDs

On Thursday, January 9, 2003, 9:36:27 PM, Claude wrote:

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

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

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.

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

Well, data oriented XML requirements have already been added to
document oriented requirements. But it may make you rest easier that
my goal in this is client-side, XML-based, multi-namespace multi-media
*documents*. Which require pointers both internally and amongst
themselves, styling (including id selectors) and scripting (including
ID based object identification).

BCLL> That is a bad outcome.

It would be. I don't see it happening.

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.

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

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.

BCLL>  That may be ok.  In SGML 
BCLL> in the mid nineties, we talked about the 
BCLL> Unicorn tests because it was self-evident 
BCLL> that we lacked precisely this kind of 
BCLL> modularization in SGML.  It worked for the 
BCLL> authors but the implementations were too 
BCLL> expensive and too rare.  The same thing 
BCLL> happened in VRML97/2.0.  So modularization 
BCLL> per se doesn't bother me.  Divesting a class 
BCLL> of users of the tools they need would.

Yes.

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.

-- 
 Chris                            mailto:chris@w3.org

Received on Friday, 10 January 2003 12:15:26 UTC