[rfc-i] xml2rfc media type and versioning

Julian Reschke julian.reschke at gmx.de
Tue Jan 28 04:09:07 PST 2014

On 2014-01-28 12:14, Erik Wilde wrote:
> 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.

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.

> - 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.

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).

Best regards, Julian

More information about the rfc-interest mailing list