[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Re: [dita] MIME type for DITA - fragment identifier issue
I vote for passing silently over the issue at this time. Do you have use cases for fragment identifiers at this time, or is it just theoretical (i.e., nice to have, or for the sake of completeness)?
Perhaps if users request support for fragment identifiers in the future, and present use cases the TC feels are applicable to a large enough set of users to warrant updating our mime type registration, we could address the issue then. With a bit of luck we'd be working on DITA 2.0 when that happens.
Hi, DITA Technical Committee:
As I mentioned at today's meeting, the proposed MIME type for DITA [1] has one remaining issue concerning fragment identifiers -- in particular, DITA references to topic subelements because the reference contains a slash (as in "#topicID/subelementID") [2].
To summarize the issue:
* DITA's scheme for subelement references conforms to the basic URI requirements for fragment identifiers [3]; however
* DITA's scheme for subelement references doesn't conform to the XPointer requirements for fragment identifiers [4]; and
* A draft proposal would require application/*+xml MIME types to conform to XPointer requirements for fragment identifiers [5].
To conform to XPointer, the subelement reference would likely need to be something like "#dita(topicID/subelementID)"
We've deferred to a future version of DITA anything that would cause backward compatibility problems for existing content, and
changing the fragment identifier scheme would definitely break existing references in content. So we can't do change that.
Also, the draft proposal may never come to fruition. The current draft has expired (though that doesn't necessarily signal abandonment).
Fundamentally, the issue comes down to a question of whether the TC wants the registered DITA MIME type to stipulate the current scheme for fragment identifiers or to pass over that issue silently.
My feeling is that we may as well stipulate the current scheme. Implementers will need to support the current scheme anyway to conform to the DITA standard. If a future version of DITA changes the fragment identifier scheme, both adopters and tool implementers will need to deprecate the old scheme and manage a migration to the new scheme, so revising the DITA MIME type at that time to identify both old and new schemes will be useful to propagate awareness of the
migration.
Many thanks to Eliot, Jeff, and especially Paul for identifying and clarifying the issue (and supplying the expert citations).
Hoping that's useful,
Erik Hennum
ehennum@us.ibm.com
[1] Note with the most recent proposal for a DITA MIME type
http://www.oasis-open.org/apps/org/workgroup/dita/email/archives/200805/msg00012.html
[2] http://docs.oasis-open.org/dita/v1.1/CD02/archspec/id.html
[3] http://www.ietf.org/rfc/rfc3986
[4] http://www.w3.org/TR/xptr-framework/
[5] http://www.w3.org/2006/02/son-of-3023/draft-murata-kohn-lilley-xml-02.txt
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]