Re: [xml-dev] Proposal (was Re: [Sax-devel] Re: SAX survey: expected localname for non-namespace qualified elements)

[Ronald Bourret <rp...@rpbourret.com>]

"Simon St.Laurent" wrote:
> I've been thinking about this unfortunate situation and think I may have a
> proposal which will let us steer through the disconnect between
> namespaces-on and namespace-off approaches as people like Glenn seem to see
> them.
> 
> How about:
> 1) The qName parameter is renamed "rawName", and documentation explains
> that this is both the Qualified Name in namespace-aware processing and the
> Name in namespace-unaware processing.

-1. rawName doesn't mean anything. qName does.

> 2) A filter which copies rawName to localName in the event that localName
> is empty or null is included in the org.xml.sax.helpers package.  This way,
> developers can adapt filters and applications which work using
> namespace-aware expectations to namespace-unaware processing without having
> to retrofit their code.

But why would we want to do this? So far, nobody has reported a parser
that doesn't report the element type name in localName when namespace
processing is turned off, and everybody (admittedly a small sample) is
writing code that relies on the value in localName. The change you
suggest would break existing applications.

I vote that we change the docs to align with current practice and remove
the ambiguity. This would be backwards incompatible in the theoretical
world but backwards compatible in the real world.

-- Ron

---------------------------------------------------------------------
To unsubscribe, e-mail: xerces-j-dev-unsubscribe@xml.apache.org
For additional commands, e-mail: xerces-j-dev-help@xml.apache.org

Re: [xml-dev] Proposal (was Re: [Sax-devel] Re: SAX survey: expected localname for non-namespace qualified elements)

[Karl Waclawek <ka...@waclawek.net>]

> At 11:56 PM 6/2/2002 -0700, Ronald Bourret wrote:
> > > How about:
> > > 1) The qName parameter is renamed "rawName", and documentation explains
> > > that this is both the Qualified Name in namespace-aware processing and the
> > > Name in namespace-unaware processing.
> >
> >-1. rawName doesn't mean anything. qName does.
> 
> Sure.  Just "name" would be fine by me.  Less meaning may be good in this case.

What if we transfer the Expat approach in a compatible way:

We define one parameter as the "Name". It contains whatever the element's
name is, regardless of NS processing on/off, regardless of the element name
belonging to a namespace or not (this means: if Prefix has a meaning,
it is not part of the name!). 

Whether the element name belongs to a namespace is determined by the URI
parameter being non-empty.

If there is a prefix, we have it in the remaining parameter.
Now, if we just have the prefix there, this would be like Expat,
and not conmpatible - so we should use prefix+':'+name.

Let's map localName to Name, and qName to the prefix parameter.
This would then mean:

- localName is always present, and reports whatever the name is,
  depending on the context (e.g. if NS processing is on, a prefix
  would not be part of the name, if the element is not in a namespace,
  localName contains the full name, ...)
- URI means what it used to mean. Empty URI means: no namespace.
- qName is present as prefix+':'+name when there is a prefix/namespace,
  otherwise it is optional. This could be changed to making it required,
  if that is better for compatibility with existing applications.

Karl


---------------------------------------------------------------------
To unsubscribe, e-mail: xerces-j-dev-unsubscribe@xml.apache.org
For additional commands, e-mail: xerces-j-dev-help@xml.apache.org

Re: [xml-dev] Proposal (was Re: [Sax-devel] Re: SAX survey:expected localname for non-namespace qualified elements)

[Ronald Bourret <rp...@rpbourret.com>]

"Simon St.Laurent" wrote:
> >But why would we want to do this? So far, nobody has reported a parser
> >that doesn't report the element type name in localName when namespace
> >processing is turned off,
> 
> Yuval Oren reported this on sax-devel:
> >My own tests show AElfred2, Crimson, Piccolo, and Xerces to return empty
> >strings for localName when namespace processing is disabled. Oracle and
> >MinML2 dodge the issue by not supporting turning off namespace processing.
> 
> That's many more than nobody.

Ah. Either I missed that or it wasn't on xml-dev. I stand corrected.

-- Ron

---------------------------------------------------------------------
To unsubscribe, e-mail: xerces-j-dev-unsubscribe@xml.apache.org
For additional commands, e-mail: xerces-j-dev-help@xml.apache.org

Re: [xml-dev] Proposal (was Re: [Sax-devel] Re: SAX survey: expected localname for non-namespace qualified elements)

["Simon St.Laurent" <si...@simonstl.com>]

At 11:56 PM 6/2/2002 -0700, Ronald Bourret wrote:
> > How about:
> > 1) The qName parameter is renamed "rawName", and documentation explains
> > that this is both the Qualified Name in namespace-aware processing and the
> > Name in namespace-unaware processing.
>
>-1. rawName doesn't mean anything. qName does.

Sure.  Just "name" would be fine by me.  Less meaning may be good in this case.

> > 2) A filter which copies rawName to localName in the event that localName
> > is empty or null is included in the org.xml.sax.helpers package.  This way,
> > developers can adapt filters and applications which work using
> > namespace-aware expectations to namespace-unaware processing without having
> > to retrofit their code.
>
>But why would we want to do this? So far, nobody has reported a parser
>that doesn't report the element type name in localName when namespace
>processing is turned off,

Yuval Oren reported this on sax-devel:
>My own tests show AElfred2, Crimson, Piccolo, and Xerces to return empty
>strings for localName when namespace processing is disabled. Oracle and
>MinML2 dodge the issue by not supporting turning off namespace processing.

That's many more than nobody.

>  and everybody (admittedly a small sample) is
>writing code that relies on the value in localName. The change you
>suggest would break existing applications.

I agree - it would would break my applications.

>I vote that we change the docs to align with current practice and remove
>the ambiguity. This would be backwards incompatible in the theoretical
>world but backwards compatible in the real world.

That's my dream, but I don't feel it likely.
Simon St.Laurent
"Every day in every way I'm getting better and better." - Emile Coue


---------------------------------------------------------------------
To unsubscribe, e-mail: xerces-j-dev-unsubscribe@xml.apache.org
For additional commands, e-mail: xerces-j-dev-help@xml.apache.org