Hi Ben,
'xsd_namespace' on the other hand expects a string literal for its value
True. And then it sets that string as namespace for cocoa ... ouch.
, which seems better for this case.
Looks as if the "namespace xsd" is indeed a but broken, as it is the
exception to the rule. I'd still vote against reactivating xsd_namespace,
not only because it is not really working either, but because it makes more
sense to make "namespace xsd" work. You probably know that we accept patches
and pull requests :-) ?
=> see THRIFT-3417
Thanks for catching this,
JensG
-----Ursprüngliche Nachricht-----
From: BCG
Sent: Wednesday, November 11, 2015 1:38 AM
To: dev@thrift.apache.org
Subject: Re: Working on a Thrift protocol on top of XML
On 11/10/2015 03:23 PM, Jens Geyer wrote:
Hi,
The xsd_namespace directive on the other hand does exactly what I need it
to do... so I was wondering if it is feasible to "un-deprecate" that
feature. It seems like this would not be a huge problem or terribly
detrimental to the project, but I don't know the background on the
decision to deprecate that feature so I won't make assumptions.
You mean that message?
'xsd_namespace' is deprecated. Use 'namespace xsd' instead
Yes, exactly.
There are a number of namespaces like XXX_namespace that fall into the
same category. Those have been deprecated long ago, in favor of the more
consistent and more easily expandable naming scheme that we have today.
What does 'xsd_namespace' do that 'xsd' cannot?
Have fun,
JensG
I was looking at this page - http://thrift.apache.org/docs/idl - and
unless I am reading this page incorrectly (which is possible!) - it
seems the namespace value must be an "Identifier", which doesn't allow
something like "http://namespace.example.com/services_and_types"; or
other sorts of things that people might like to do when concocting their
XML namespaces. 'xsd_namespace' on the other hand expects a string
literal for its value, which seems better for this case.
Thanks
Ben
