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] Versioning of DITA public identifiers


I started to write (read to the end of extract before you reply):
 
[[
 
I might be missing or forgetting something, but I don't think there is a problem,
and I am quite sure I don't want to version DITA's public identifier (which is
I think what you mean by "versioning the DOCTYPE DECL for DITA 1.1").
 
We designed 1.1 to be upward compatible with 1.0, and content isn't versioned,
so I don't see what it means to be "1.0 content" so I don't see what it means
to have "a mix of 1.1 and 1.0 topics".
 
If you have a 1.0 DTD and you try to validate content that uses things added
in 1.1, it won't validate. So don't do that. You can't expect an old system to
handle new stuff.  Upgrade your system to use the DITA 1.1 application.
 
Now your new system should work fine on all your DITA (1.0 and 1.1) content.
 
]]
 
and then I checked and noted that we are setting the DITAArchVersion to 1.1
and making it FIXED in the 1.1 DTDs.
 
As long as your editor doesn't explicitly set DITAArchVersion and your application
doesn't push defaulted values from the DTD into the instance, you'll be okay, but
if your application does push defaulted values from the DTD into the instance
(which I'm guessing Documentum might do), I can see that you are versioning
your content, and then I do see Scott's problem (though I still don't think the
solution is to version the public identifier).
 
If 1.1 is upward compatible with 1.0, then why are we changing the value of the
DITAArchVersion attribute?  And do we really want it to be fixed?
 
paul
 


From: Scott Hudson [mailto:scott.hudson@flatironssolutions.com]
Sent: Monday, 2006 October 09 13:11
To: dita@lists.oasis-open.org
Subject: [dita] Versioning of DITA public identifiers

Where did we (DITA TC) end up on versioning the DOCTYPE DECL for DITA 1.1?

From the open action items list
(http://www.oasis-open.org/apps/org/workgroup/dita/members/action_item.php?action_item_id=1016)
this still appears to be an open item.

I understand that if you create a specialization, you are creating a new
public identifier for it. The problem is more around content that is
validating against the base DITA standard.

Currently, (as I understand it), the base DTDs will not have a version
number embedded in the public identifier, even though the DTD has
changed. This was a
"conscious" design feature to not embed version info in an attempt to
continue backwards compatibility.

Unfortunately, this means you may have 1.1 content that would not
validate against a 1.0 DTD, and the system wouldn't be able to tell
which DTD it should use to validate the content against. It also would
fail in a hybrid doc, where there is a mix of 1.1 and 1.0 topics.

If the DOCTYPE DECL is not rev'd, it's going to wreak havoc with
Documentum XML apps. Since the version number is embedded as a fixed
CDATA element, files that were checked into the store will no longer
parse correctly if the DTD is upgraded. The only way to fix this
problem to make a new XML application for each DTD version. To upgrade a
document that previously exists in the Docbase, you have to export
it, change the version numbers and then re-import it so that it gets
associated with the "correct" app.

Here's what happens when we try to import a "new" version document with
the "old" DTD:

Attribute "ditaarch:DITAArchVersion" with value "1.1" must have a value
of
"1.0". Line 86, column 64
,file:C:/Documentum/contentXfer/webtop/sqlserver-2006.10.06-1131h.50s_42
085/
128215d1q10e1eae52ac1q1d8000/10042122.xml

Another area that this affects is XML Catalogs; It's been standard
practice to put the version in the Public ID so that you can include and
reference specific DTD instances locally (typical scenario is to have a
"stable version" and a "test version" of different versions of a DTD to
evaluate compatibility issues). Most catalog resolvers key on the Public
ID to look for a local reference of a DTD.

Based on previous threads, I know that the catalog issue has been pushed
to DITA 1.2, however, I think the DTD rev issue is something we need to
address in DITA 1.1.

Best regards,

--Scott


[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]