[rfc-i] xml2rfc media type and versioning

Erik Wilde dret at berkeley.edu
Wed Jan 29 01:36:34 PST 2014

hello julian.

On 2014-01-28, 13:09 , Julian Reschke wrote:
> On 2014-01-28 12:14, Erik Wilde wrote:
>> 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.
> I think this is a non-target, as there are existing v2 implementations
> no one wants to touch. We are not designing something new here.

fair enough. but we are trying to document something that hasn't been 
thoroughly documented before, right? so at least documenting how 
extensibility is or isn't supported may be a worthwhile addition. and it 
helps with the media type issue (which is where this discussion started).

>> 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.
> What we can say is:
> - v2 processors might be broken by v3 content
> - v3 processors ought to handle v2 content (unless we decide otherwise
> at a point in the future)
> ...and then maybe a rule how to run experiments with new elements. Such
> as using elements in a custom namespace, and then have rules when how to
> ignore those (where I believe it depends on the context in where they
> appear in).

sounds like a good starting point. the question then is whether for a v3 
processor, there's some signal that it can use to branch into v2 or v3 
behavior, or whether it can simply process v2/v3 in the same way. from 
what i've heard so far, the latter seems to be the goal, but it may be 
tricky if things such as v3 lists are using markup structures that are 
rather different from their v2 counterparts.



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