ExtendedProperty doesn't accept long URIs for property name

[GoogleCodeExporter]

What steps will reproduce the problem?
I'm trying to add extendedproperties for Calendar.EventEntity:
 property = new ExtendedProperty();
 property.Name = "http://www.example.com/schemas/2005/a#mycal.id";                          
 property.Value = "any";
 toCreate.ExtensionElements.Add(property);      

What is the expected output? What do you see instead?
 I should see gd:ExtendedProperty sent in Feed. But now all elements that 
have name longer than 45 characters are NOT included in the insert feed.You 
could try that sample above - it will not work, while if you remove "/a" it 
will (like in samples file).

 Also, if you have 3 properties:
A (with short name)
B (with long name)
C (with short name)

only A will be added (I guess that is due to exception in B handling)

What version of the product are you using? On what operating system?
 - Calendar
 - latest API from SVN

----
Thanks

Original issue reported on code.google.com by lek...@gmail.com on 6 Apr 2009 at 11:12

[GoogleCodeExporter]

need to debug this. If you have time to send me the http trace for that 
request, that would be great. 

Original comment by fman...@gmail.com on 23 Apr 2009 at 4:12

• Changed state: Reviewed

[GoogleCodeExporter]

Did debug this. Following test code:

 private void button1_Click(object sender, EventArgs e)
        {
            ContactEntry c = new ContactEntry();
            ExtendedProperty property; 
            property = new ExtendedProperty();
            property.Name = "http://www.example.com/schemas/2005/a#mycal.id";
            property.Value = "any";
            c.ExtensionElements.Add(property);
            MemoryStream s = new MemoryStream();
            c.SaveToXml(s);
            MessageBox.Show(GetStringFromMemoryStream(s));

        }

        public static string GetStringFromMemoryStream(MemoryStream m)
        {
            if (m == null || m.Length == 0)
                return null;

            m.Flush();
            m.Position = 0;
            StreamReader sr = new StreamReader(m);
            string s = sr.ReadToEnd();

            return s;
        }

shows there is no problem persisting this kind of URI, the XML looks perfectly 
valid. 

Original comment by fman...@gmail.com on 13 May 2009 at 1:57

• Changed state: ByDesign

[GoogleCodeExporter]

Hello,

Thank you for debugging that issue. I've double-checked and it's still there.

Let me provide more info re that.

You are right, the XML that is sent to Google is correct.
But long extended properties are not saved and thus are not returned in 
resulting XML 
feed. You can check that with Fiddler.

You can check that the following way:
1) when you submit INSERT statement into the feed Google returns item feed with 
full 
details of inserted entity.

2) If you have long extended property name, it's not inserted and there is no 
gd:ExtendedProperty in returned XML. 

3) While if it's short - it's there.

I think that is related to internal Google API, not to .NET wrapper API. But 
probably 
you are aware of internals behind that, so you can add some blocking / warning 
code, 
as now it allows entering long extended properties, while they are not saved 
and it's 
very confusing.

Also, I've reviewed GBase docs recently and found 1 note about limitation on 
Attributes. http://code.google.com/intl/uk-UA/apis/base/starting-out.html

I guess extended properties are implemented using GBase items, and their 
attribute 
labels cannot be longer than 40 characters - same as we have with extended 
property 
issue discussed here. Probably that is the root cause.

Thanks,
Alexei

Original comment by lek...@gmail.com on 14 May 2009 at 7:14

[GoogleCodeExporter]

This buglist is for reporting/suspecting/verifying issues inside the .NET 
client, hence, i made sure first that 
this is not something my code screwed up :) 

From what you are outlining this seems to be clearly an issue with the calendar 
service. You should report the 
bug, star it etc here:

http://code.google.com/p/gdata-issues/

so that the calendar team knows about it. Link this bug to it, so that they 
also know this was verified 
(otherwise they probably send you back here :)). 

I think having an upper limit is fine on the lenght of the attribute, but it 
deserves a more consistent error 
handling.

Original comment by fman...@gmail.com on 14 May 2009 at 8:09