OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.


Help: OASIS Mailing Lists Help | MarkMail Help

dita message

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

I agree with Paul (in a later email) that we should rather adopt good W3C standards than ignore them. The same probably applies to XInclude, which long-term may offer a superior solution to conref. I know of at least one tool that uses the same underlying application code to support both conref (for DITA) and XInclude (for other DTD/Schema). Obviously such radical changes cannot be made until we make a major release, where we can introduce backwards incompatibility.
Gershon L Joseph
Director of Technology and Single Sourcing
Tech-Tav Documentation Ltd.

Secretary, OASIS DITA Technical Committee
Secretary, OASIS DITA Translation Subcommittee
Member, OASIS DocBook Technical Committee

+972-8-974-1569 (direct)
+972-57-314-1170 (mobile)

----- Original Message ----
From: Erik Hennum <ehennum@us.ibm.com>
To: dita@lists.oasis-open.org
Sent: Wednesday, May 14, 2008 1:18:02 AM
Subject: [dita] MIME type for DITA - fragment identifier issue

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

[1] Note with the most recent proposal for a DITA MIME type
[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]