RE: [xml-dev] Re: determining ID-ness in XML

["Bullard, Claude L (Len)" <clbullar@ingr.com>]

Of all the attempts at requirements posted, the one 
that stood out was the problems with streaming. 
I would like to see these expanded and the 
arguments pro and con against each of the three 
solutions weighed against the impact on streaming. 

If there are other technical arguments ('we don't 
like it' is not a technical argument), post those 
and compare the proposed solutions.

I like the three categories you pose, but at the 
same time, I see another layer of XML complexity 
emerging that tells me we are getting further 
away from the original XML requirements.  Instance 
only XML is RTF come back.  Where is the boundary 
of well-formedness and validity?  We are breaking 
that down.

And we are clueless about the effects of this 
in a system with other content processors.  XML 
may be building it's own island of automation. 
Architecture must consider the big picture. 
80/20 minimalist thinking here is XML fratricide.

len

-----Original Message-----
From: Rick Jelliffe [mailto:ricko@allette.com.au]



 From: "James Clark" <jjc@jclark.com>

> The problem that xml:id is not completely solving the problem, at least as

> I see it. 

Why do we need a complete solution?  We need to have broad solutions
apppropriate for different classes of users.

> Overall xml:id is pretty intrusive.

If it were couple with the rule that unknown entity references are resolved
against the ISO standard entity sets (i.e. build the ISO sets into XML),
then it would allow DTD-less documents, suitable for lightweight, well-known
and informal systems.

That would let us move to three forms of XML:

 1) Instance-only XML  (=WF XML - DTD + xml:id + xmlns + ISO entities +
xml:base + xml:include + xlink)
 2) Classic XML (= Valid XML + namespaces) 
 3) PSVI-convertable XML (e.g. XML + XML Schemas)
 
I think that would be a pretty healthy split.  I believe most users of XML
would 
head towards Instance-only XML, especially since it still could be validated
(by RELAX, 
by XML Schema, by Schematron).    The database and tools-making companies 
would continue to take the PSVI-based XML track, I would guess.
 
> An alternative would be to have an attribute that declares the name of the

> attribute that is an ID attribute, say xml:idatt. To make this useable, 
> xml:idatt would be inherited.  

By the time we factor in inheritence, we may as well have a schema language.

I think the answer to the "problem" should come architecturally, rather than
solving
small problems.  The architectural solution is IMHO to have a clear roadmap
for different kinds of XML, and to avoid one-size-fits-all-ism.