Personal view

 Speaking without any W3C hat on, just as the developper of libxml library,
personally I have a problem with the absolutize option. It's related
to the fact that the following sequences of bits:

-----------------
<x xmlns:n1="http://www.example.org/a xmlns:n2="/a">
  <test n1:y="1" n2:y="2"/>
</x>
-----------------

would be a perfectly good XML-1.0+NS resource *except* if served as a
resource coming from the server http://www.example.org (unless I
really seriously misunderstood either REC-xml-names or the 
absolutize option, still possible even after 1400+ mails :-\,
in that case, please correct me !).
Assuming I made no mistake, this is the kind of errors hard to
detect and handle in practice, and having the correctness of a resource
depending on the address it's served from sounds seriously disturbing
to me.

 The simple string comparison has the advantage of simplicity,
and should be slightly less costly (in time/memory requirements)
but denies the fact that namespace name are URI references (and
then possible anchors for associated namespace related metadata).

I also note that the current section 6. Conformance of Documents
in the namespace REC nor 5.3 really says what an XML processor
- in the general sense - should do with document not conforming to
this spec, they still look well formed XML-1.0 stricly speaking,
should the data be made available to the application with just
a warning, or should this be considered an extension of a Well Formedness
error - which is the case for redundant attributes at the XML-1.0
level.

 My personal opinion is still that relative URI in namespaces should
be deprecated, this will avoid a number of problems with existing and
upcoming specifications. I would also suggest as a guideline in the
revision of the namespace specification that steps 6 c) 6 d) 6 e) and
6 f) of the algorithm specified in the section
  5.2. Resolving Relative References to Absolute Form
of the rfc2396 should be applied to URI expected to be used as namespace
name (i.e. before namespace name creation, not when handling them). So
that "http://www.example.org/./a" is still a valid namespace name,
but be clearly flagged as "bad practice". I would also like to see
the namespace spec extended to say what should happen to non
conformant document, should this be considered like a WF error,
or should a simple warning-like error be raised ?

  In that case is seems to me that DOM 2 path to REC will require few
further processing from the Working Group, XPath-1.0 looks good too,
XML Base can clearly state that XML Base doesn't impact Namespaces in
XML (instead of non-normatively as in the current LC draft), and I assume
nothing need to be changed for XML infoset either.

Daniel (again speaking for himself)

-- 
Daniel.Veillard@w3.org | W3C, INRIA Rhone-Alpes  | Today's Bookmarks :
Tel : +33 476 615 257  | 655, avenue de l'Europe | Linux XML libxml WWW
Fax : +33 476 615 207  | 38330 Montbonnot FRANCE | Gnome rpm2html rpmfind
 http://www.w3.org/People/all#veillard%40w3.org  | RPM badminton Kaffe

Received on Saturday, 17 June 2000 05:18:48 UTC