Cart
[Home] [By Thread] [By Date] [Recent Entries]
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
|
