Unknown fields are not serialized to XML or JSON formats

[GoogleCodeExporter]

What steps will reproduce the problem?
1. Create Message with unknown fields
2. Try to serialize to xml

What is the expected output? What do you see instead?
Expect to see unknown field in xml output, instead field is not there.

What version of the product are you using? On what operating system?
Google.ProtocolBuffers.2.4.1.521 win7

Please provide any additional information below.
Was wondering if there was a reason this was left unimplemented. 

AbstractWriter.cs

void ICodedOutputStream.WriteUnknownGroup(int fieldNumber, IMessageLite value)
{
}

void ICodedOutputStream.WriteUnknownBytes(int fieldNumber, ByteString value)
{
}

void ICodedOutputStream.WriteUnknownField(int fieldNumber, WireFormat.WireType 
type, ulong value)
{
}

Original issue reported on code.google.com by jbol...@gmail.com on 13 Aug 2014 at 4:48

[GoogleCodeExporter]

[deleted comment]

[GoogleCodeExporter]

Any update on this?

Original comment by jbol...@gmail.com on 15 Sep 2014 at 5:45

[GoogleCodeExporter]

I haven't had a chance to look at it yet, I'm afraid. Roger was behind the 
original XML implementation I believe - I'll ping him for comment...

Original comment by jonathan.skeet on 15 Sep 2014 at 5:55

[GoogleCodeExporter]

Thanks for the reply! I appreciate any help you can offer. This would be very 
useful for my team.

Original comment by jbol...@gmail.com on 15 Sep 2014 at 6:03

[GoogleCodeExporter]

We actually looked into this in the beginning.  Mostly we looked at the 
use-cases, what are they and why do we want to support this?

The original goals of adding json/xml support was to:
- Allow messages to be persisted in a human readable, modifiable format.  
- Allow foreign systems of any language to communicate with a protobuf 
described service.

Neither of these use-cases need nor even could take advantage of unknown 
fields.  When we considered them we thought perhaps consumers might want to ....

1. Interpret unknown xml/json elements and be able to save them back out again.

This proved practically impossible to implement without constraining the 
unknown fields to a particular serialization type.  Thus if you support #1 and 
read an unknown field from xml, then serialize the message between systems via 
protobuf, you can then no longer recreate the xml.  This seemed undesirable and 
likely to 'surprise' the consumer.

2. Round-trip unknown proto buffer fields to/from xml or json.

This can only 'partly' be implemented.  The unknown fields don't know enough 
about their type to be interpreted into any 'raw' value.  As such the best you 
could accomplish is storing a binary blob for each unknown field.  This 
approach seemed rather dissatisfactory to either of the original use-cases.  

In the end we found that the cost of allowing unknown fields was not in line 
with the limited, and potentially negative, impact of supporting them.  I would 
be interested in hearing why you would want this behavior and what you might 
use it for?

Original comment by Grig...@gmail.com on 15 Sep 2014 at 7:53

• Added labels: Type-Enhancement, Priority-Low
• Removed labels: Type-Defect, Priority-Medium

[GoogleCodeExporter]

closing as Won't Fix as we have not identified a use-case to serve with this 
feature.

Original comment by Grig...@gmail.com on 30 Jan 2015 at 6:25

• Changed state: WontFix