Don Box and Dave Winer agree

December 21, 2006 at 2:18 am · Filed under Web 2.0

Two guys who know a thing or two about web services and APIs think the new Google Search API is a step backwards.  I agree.

My guess is that some high up at Google thinks of it as a step forwards.  Perhaps someone asked the question:

Why are we providing search results into arbitrary applications, when in fact, we are in the business of serving ads on Web pages?

An AJAX-only API is a fine way to do just that; but like Don Box says:

No matter how you define “web service,” I don’t think this newest offering qualifies.

I’m hoping this is just an anomaly and not a trend, lest we all fall back into the world of opaque/closed protocols.

Google doesn’t have to provide open and interoperable APIs to the world; but, I bet others will. 

Tags: ajax, APIs, Google, Search, SOAP, Web-Services, XML

Comments (2)

XmlSerializer and ObsoleteAttribute redux

August 14, 2006 at 6:33 am · Filed under .NET

Recently I complained about how the XmlSerializer treats the ObsoleteAttribute.

My desire was to deprecate a property with ObsoleteAttribute without it being ignored by the XmlSerializer. I still think that the attribute should be ignored for serialization, but here is a workaround:

Before:

[XmlAttribute]
public bool A { ... }

After:

[Obsolete("This property has been deprecated; use property B instead.")]
[XmlIgnore]
public bool A { ... }

[XmlAttribute("A")]
[EditorBrowseable(EditorBrowseableState.Never)]
public bool DeserializingA { ... }

[XmlAttribute]
[DefaultValue(false)]
public bool B { ... }

The ObsoleteAttribute tells the compiler to issue warnings to developers about the old property (and, as I said above, the XmlSerializer also ignores it).

The XmlAttribute.Name property directs the serializer to read a property from an XML attribute with a different name.

The EditorBrowseableAttribute hides the deserializing property from Intellisense. You can also hide it from the debugger using the DebuggerBrowseableAttribute (not shown).

The example shows this for XML attributes, but the same approach will work for other XML elements.

Not too much extra work, though I would still prefer the XmlSerializer to just ignore the ObsoleteAttribute.

Tags: .NET, XML

Comments (1)

XmlSerializer should ignore ObsoleteAttribute . . .

August 8, 2006 at 12:37 pm · Filed under .NET

. . . or respect the IsError property.

I found a problem in some code today. The class is a data-holder for XML serialization. One property has been deprecated and attributed with the ObsoleteAttribute to produce a compile-time warning for developers. Previous versions of the XML data must still be readable, but we want to make sure all of our code uses the correct property.

I assumed that on XML-deserialization, the property-setter would be respected; however, it is not.

This is wrong.

If a member is marked as obsolete with warning (i.e., deprecated) it should still be observed.  This is the case throughout .NET 2.0: deprecated members continue to function compatibly.
The only way that I can see the XmlSerializer observing this attribute is if IsError == true; however, even this is a stretch.  Really, this attribute should only impact compilation, not runtime.
Better yet, if a user wants a new version to exclude deserialization, we already have an attribute for that:  the XmlIgnoreAttribute.
Argh.

Tags: .NET, XML

Comments (3)