[rfc-i] xml2rfc media type and versioning
julian.reschke at gmx.de
Tue Jan 28 02:57:24 PST 2014
On 2014-01-28 10:50, Erik Wilde wrote:
> hello julian.
> On 2014-01-28, 10:33 , Julian Reschke wrote:
>> On 2014-01-28 09:01, Erik Wilde wrote:
>>> if it is intended to make v2 and v3 compatible in both directions (v2
>>> documents can be meaningfully processed by a v3 processor, and v3
>>> documents can be meaningfully processed by a v2 processor), then it
>>> definitely would be great to have just one media type. is such a
>>> versioning design planned?
>> That is my intent.
>>> if the answer to this question is yes, then i would propose that the
>>> xml2rfc v2 vocabulary draft gets an "extensibility model" section, in
>>> which it is explained what extension points the vocabulary has, and how
>>> processors have to handle them. v3 then needs to make sure that it stays
>>> within the bounds of this model.
>> 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).
> 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
>> I believe that would be total overkill, given the fact that we've used
>> xml2rfc without a media type. It should be sufficient if the content
>> contains sufficient for a processor to do the right thing. As long as we
>> don't change the interpretation of existing elements significantly,
>> there shouldn't be any problem.
> 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.
Best regards, Julian
More information about the rfc-interest