[standards-jig] Re: [JDEV] XML Conformance

[Daniel Veillard]

On Thu, Jan 17, 2002 at 08:46:03AM -0600, Julian Missig wrote:
> /me admits defeat and crossposts

  :-)

> >>So therefore, ids may start with a letter, an underscore, or a colon, 
> >>and then have all the numbers your pretty little heart desires. However, 
> >>'2' is not a valid id.
> 
> Right now, there's nothing to base validity off of, but we do plan on 
> eventually having schemas some day, which is why I brought it up.

  yep this would definitely suit Jabber use better (namespace support and
composition).

> Hrmm, I see what you're saying. So you feel there's nothing wrong with 
> requiring clients and servers to support prefixes? I'm just under the 
> impression that things like palm clients will have difficulty with that, 
>   moreso than it would be difficult to require they not be used... 
> Correct me if I'm wrong ;)

  I'm afraid that imposing extra rules will require using specific code,
PalOs probably already have XML handling, possibly in ROM. Not sure such
a requirement would be taht better in this case. Less deviation means
more standard tools, simpler to develop and less buggy products -- in
theory at least :-).

> Are there really that many XML Namespaces-conforming parsers which will randomly
> start using prefixes which cannot be turned off? From my point of view, it's more
> difficult for many parts of jabber to support prefixes. Servers will have to keep
> track of all the prefixes a client uses...because a client could declare a prefix
> when sending to one person and use it in a message to another, so the server will
> have to tack the xmlns:prefix definition on the packets sent to other people.

  Yes you have to keep track of prefixes. I don't see how you could avoid this
in any case.

> Prefixes also hurt stream compression and any routing optimizations since the tag
> names could be virtually anything (There has already been some work on routing
> optimization since the basic structure of most Jabber packets is very similar - it
> would be somewhat negated by having to support namespace prefixes, and I get the
> feeling that SSL compression won't be as effective when prefixes are changing). So

   You're trying to optimize too early. Build and test, then optimize.
If the application wants to optimize its serialization rules, the last thing
it may want are rules about what prefixes really need to be made default ones.
one can have only one one element prefix per element but potentially dozens
of namespace prefixes on attributes. And there are subtles rules about 
default namespaces and attributes.

> from my point of view it seems easier and more efficient to not allow prefixes. I
> know in Gabber it will take a major overhaul of Jabberoo and Gabber to properly
> support prefixes. Also, are XML Namespace-conforming parsers available everywhere we
> have Jabber clients right now? I know it could be argued that the existing XML
> parsers should be made XML Namespace-conforming, but it's an additional argument
> against it in Jabber.

  The namespace conformance can be implemented on top of non-namespace aware
this does not stand. Yes you have to keep a list of in-scope namespaces
at a given point at parse time.

> No, I don't think printf() is the way to go ;) - I do want conforming parsers, but it
> may be possible for us to get away with not requiring a fully Namespace-conforming
> parser...

  Either you use namespaces or not. If you don't you can't extend
properly the protocol and Jabber might be usuable as an XML transport
platform, and considering the weight of XML based protocols at the moment
this doesn't sound good.

Daniel

-- 
Daniel Veillard      | Red Hat Network https://rhn.redhat.com/
veillard at redhat.com  | libxml Gnome XML XSLT toolkit  http://xmlsoft.org/
http://veillard.com/ | Rpmfind RPM search engine http://rpmfind.net/