Re: Re: [stax_builders] Once more about XMLStreamReader, setPrefix()

--- Aleksander Slominski <[email protected]>
wrote:

..
> >Although the example in 1.0 specs seems
> >straight-forward enough:
> >
> we do *need* to fix this!!!!

I agree. I just attended a session at "No fluff just
stuff" symposium (RMSS), which interestingly enough
had a session that covered StAX as a
"recommended practice" (!). And I realized that many
people do consider writer side important too,
as a stand-alone thing.

And obviously it's also needed in pass-through
processing (transformations, soap msg dispatching etc)

> 
> now the tricky part id if we can fix it by
> clarifying spec and RI or it 
> is hopeless?

I think it can be resolved. It's mostly a problem
with specification almost omitting writer side...
but even then RI seems to be non-compliant. :-)
Fortunately RI's code is quite simple, so it should
be possible to fix.

> agree about and 
> implement in RI and all other StAX parser IMHO.

Exactly.

I think problem can divided in couple of separate
parts.
First of all, repairing and non-repairing modes
are rather distinct; they probably should be specified
separately.
First thing at high level would be to  specify what
are
the goals of these modes.

My thinking is that:

* Non-repairing mode is raw, highly efficient, and
  should do minimal checking (at least by default).
  Specifically, it shouldn't verify namespace
  consistency (with one exception, more about this
  below).
* Repairing mode is highly robust mode (WRT
namespaces)
  and should basically only use passed prefixes as
  suggestions. And from thereon, make sure that
  namespaces used do work as specified, using URIs
  specified as intended. If prefix usage is 
   inconsistent, it should use right prefixes to
  map to requested URIs.

If so, rules can be derived from these.

The second separation I see is the difference between
1-, 2- and 3-argument modes for elements (and
similarly
2/3/4 argument for attributes, as there's value too).
My thinking about these is as follows:

* 1-argument is simple: it's just local name, with no
  namespace info: assumption is it should use current
  default NS (elements), or no NS (attributes).
Nothing
  special, no checks in either mode
* 3-argument one is also quite simple: in
non-repairing
  mode output is done using prefix/localname pair as
is,
  and URI is pretty much ignored (unless some extra
  checking is enabled).
  In repairing mode it's reversed: URI is to be mapped
  correctly, prefix is only a suggestion
* 2-argument one is easy in repairing mode: it acts
like
  3-argument one, except there's no suggested prefix.
  In non-repairing mode, it has to rely on setPrefix()
  to find intended prefix: if none found, exception
  is to be thrown.

And the last tricky thing, then, is use of setPrefix()
and writeNamespace() (and the other 2 methods for
default
NS).

In repairing mode, I see both of these are redundant
and
unnecessary. setPrefix() could potentially be used to
suggest certain prefix/URI mappings, but writer can
(and should) override these if necessary to output
correct prefixes to get requested URI as namespace.
I don't see any use for calling writeNamespace() in
repairing mode: in this mode writer should output
namespace declarations automatically as needed.

In non-repairing mode there are more possibilities,
but based on my reading of xmlpull (as predecessor),
I think that:

(a) setPrefix() is ONLY needed if/when using
2-argument
  output methods
(b) writeNamespace() is ALWAYS needed for each
namespace,
  independent of whether setPrefix() is used or not.

One more question about setPrefix(): if it's used,
what
is its scope. Xmlpull would suggest it is the scope of
immediately following start element. That seems the
most
logical choice. Other alternatives are that it binds
to
currently open start element (immediately preceding),
or to the rest of the document (not bound to XML tree
but to writer's life cycle).

What do you think? Does this make sense?

-+ Tatu +-



		
__________________________________ 
Do you Yahoo!? 
Check out the new Yahoo! Front Page. 
www.yahoo.com 
 



------------------------ Yahoo! Groups Sponsor --------------------~--> 
Make a clean sweep of pop-up ads. Yahoo! Companion Toolbar.
Now with Pop-Up Blocker. Get it for free!
http://us.click.yahoo.com/L5YrjA/eSIIAA/yQLSAA/2U_rlB/TM
--------------------------------------------------------------------~-> 

 
Yahoo! Groups Links

<*> To visit your group on the web, go to:
    http://groups.yahoo.com/group/xmlpull-dev/

<*> To unsubscribe from this group, send an email to:
    [email protected]

<*> Your use of Yahoo! Groups is subject to:
    http://docs.yahoo.com/info/terms/