On 11/11/2015 03:52 PM, Jens Geyer wrote:
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.
I remember noticing that in the output from the JSON generator...
confusing to say the least.
, 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
I agree with your vote... I suppose that in theory removing support for
that directive could break existing IDL that includes it... but in
practice I suspect it is not widely used. Especially since the XSD
generator doesn't actually generate a valid XML schema :) Even if it
does break existing IDL files, fixing the "broken" IDL would be simple.
Anyways, I was thinking about a possible solution, and this is what I
came up with - support for annotations on namespace declarations.
I believe this would provide ample flexibility, and perhaps not just for
the XSD case. It could be of use in any IDL where package-level
metadata might come in handy.
Specifically, in my case it could look like this:
namespace xsd my (uri = 'http://my.example.com/namespace/or/whatever')
In the example above, I'd use "my" as the default namespace prefix for
the module, and then the annotation value for the namespace URI, so my
problem would be solved. I imagine there might be useful things that
could be done with this for other languages as well... for example maybe
one could use it to tell the Java generator to add a package-info.java
file, etc. In any case, this is the best solution I could come up with
that is at least somewhat consistent with other parts of the IDL grammar.
I can implement this and submit a patch if you think that this is a
sensible solution.
Thanks,
Ben
-----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
band 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
