[rfc-i] xml2rfc media type and versioning

Erik Wilde dret at berkeley.edu
Tue Jan 28 03:14:02 PST 2014

hello julian.

On 2014-01-28, 11:57 , Julian Reschke wrote:
> On 2014-01-28 10:50, Erik Wilde wrote:
>> On 2014-01-28, 10:33 , Julian Reschke wrote:
>>> On 2014-01-28 09:01, Erik Wilde wrote:
>>> That'll be tricky :-) Do you have a concrete proposal?
>> not yet, but i can work on something. i don't think that without such a
>> section it would be wise to not have (some form of) explicit versioning.
>> the extensibility model could be as simple as HTML's rule to ignore
>> unknown element tags and attributes, but to process the contents of
>> unknown elements. i am not sure this exact model would work for xml2rfc,
> The problem is that the xml2rfc vocabulary's design is different from
> HTML's. We have many cases where text content does not directly go into
> what's displayed, and the other way around (section titles in attributes).

yes, that indeed may make things a bit more tricky than in HTML's case.

>> but i think this is the kind of extensibility model that is required if
>> the goal is full compatibility across vocabulary versions.
> I don't think we "full compatibility". What's needed is that recipients
> can figure out what the document means. This does not necessarily
> require versioning.

but doesn't that imply one of two choices:

- recipients can simply process a document without having to branch into 
different processing models. in this case, there must be some 
"extensibility model" (maybe that's a bad name), so that a v2-capable 
recipient will not fail when processing a v3 document.

- there are different explicit processing models, and recipients have a 
way to determine the version, and then apply the respective model, or 
stop if they encounter an unsupported version.

>> that's fine, and probably a good goal to have. but given that there
>> probably will be v2 and v3 documents floating around for a while, it
>> would be good to have it spelled out how they are distinguished, and how
>> they are processed.
> v2 describes the semantics of v2 documents. v3 will describe the
> semantics of v3 documents. If we don't change semantics of existing
> elements, that should be sufficient.

maybe i am being too strict here. but to me it seems that you have two 
choices listed above, or as a third possibility, you simply accept that 
different recipients might do/understand different things. maybe this 
ecosystem is small/controlled enough that what i proposing indeed is 
some overkill, but regardless of which model is chosen, i think it would 
be very useful to spell it out somewhere.



erik wilde | mailto:dret at berkeley.edu  -  tel:+1-510-2061079 |
            | UC Berkeley  -  School of Information (ISchool) |
            | http://dret.net/netdret http://twitter.com/dret |

More information about the rfc-interest mailing list