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

["Jonathan Borden" <jborden@mediaone.net>]

Len,


> That is one explanation.   However:
>
> 1.  No one has stated a requirement that the name actually
> be an ID.  A name will do.  (see elliotte).  If a
> name will do, this is a nameloc and there is not a gaping
> hole in the architecture.

Certainly, but let's examine this: We define an "ID" as an XML 1.0 ID _which
is only defined by a DTD_. A "nameloc" is ? a general way of defining an
_identitier_. If so then "xml:id" does not define an "ID" rather a
"nameloc".

>
> 2.  If that is not the case, and it must be an ID, then
> what the xml:id proposal does is begin to marginalize
> the use of DTDs.

In all cases an "xml:id" is _not_ the XML 1.0 ID (since it is not mentioned
in XML 1.0). It can be sa way to define what a raw fragment identifier name
points to.

>
> Not without a bounded scope, Jonathan.  The days
> of the freedom of the XML core groups to obscure
> by misdirection such notions are over.  Never Another
> "Namespace Is Just A Disambiguating String" ploy.

He, he, you believed that? :-)

I would rather like to think that _disambiguating_ was a good point of
common agreement at the time, and that further agreement on what a namespace
name might indicate was waiting for a later date. For example RDDL, while it
may not have achieved _universal_ agreement, has gone some way toward being
and agreement point around which we can define further characheristics of
what a namespace name indicates.

>
> All requirements up front, clear, and signed.
> Otherwise, no change.  It costs too much to
> allow the children to play in the design these days.

Similarly it costs too much _not_ to move forward when real problems need to
be solved. In a perfect world world we would all know our requirements, have
the same requirements, and agree on the solutions to these requirements. Yet
the world ain't perfect and we have code to write nonetheless.

Jonathan