[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
RE: [xml-dev] Re: determining ID-ness in XML
Only that the xml:id attribute needs to be supported
and probably in a wide variety of xml processors. The
xml namespace is the system vocabulary because XML itself
reserves it. If we really want it to be a looser contract,
it should be a PI. I don't think we do want it to be a
loose contract. What we have to understand is that everytime
one of these is added:
1. The system vocabulary expands and xml starts to look
like rtf. That is in principle, ok, but we have to be
very reasonable about what we ask for. Given XPointer,
xml:id seems reasonable. Yes, pre-web markup hypertext
systems used this approach and were beat up by the
pre-XML hypertext crowd for doing it. It's a known.
2. Yet expansions like that are expensive and get more
so every time we add one because of tool churning.
So, the idea that these architectural gaps can
sort of "creep out" is unreasonable in the extreme.
Again, we just end up saying "whatever MS wants is fine"
because we are tied to a tools release schedule. XML
is core. It can't perturbate wildly and interdocument
references based on a reserved target type are even
more fundamental: they are doctrine, so this kind of
thing can't lay around waiting for the opportune time
to propose it.
If xml:id is "just a name", then change the name
to something like "xml:label". That will save us
an enormous amount of explanation and misunderstanding
with the DTD/Schema authors. If however, this
change is only the camel's nose, then we have to say
no, hell no, and stop the architecture group in their
tracks until they present the whole plan and the
requirements that drive the plan. Otherwise, see item 2.
len
-----Original Message-----
From: Elliotte Rusty Harold [mailto:elharo@metalab.unc.edu]
Let me phrase the question this way: regarding validity and validity
only, not the semantics of the attribute, is there any objection to
an xml:id attribute that is not equally true of xml:base? So far I