Bug 869129

Is there any intention to allow the CCMS to transform XML between DocTypes? If not it seems a bit odd to put the onus of selecting the DocType on the requesting party rather than the system that actually stores the XML and the metadata that describes it.

NB: Topic Tool bugs/requests still belong here:

https://bugzilla.redhat.com/enter_bug.cgi?product=Topic Tool&component=cli-Topic_Tool

Currently there isn't however eventually we would like to allow Docbook 5. So this was mainly allowing 2 things:

1. Get the XML as it is without adding any DTD or XML definitions.
2. Allow future doctypes.

However after discussing it more thoroughly at our meeting today, we are going to create a field on topics to specify the doctype and use that to return the correct doctype for those endpoints. However that will be a bit more down the track (but still not worth supporting in the Topic Tool).

The other reason for the patch is to allow topic Revisions to be pulled and keep the topic ID. Eg

/topic/get/xml/32/r/19039/xml

Also thanks Steve for the link.

(In reply to comment #3)
> Currently there isn't however eventually we would like to allow Docbook 5.
> So this was mainly allowing 2 things:
> 
> 1. Get the XML as it is without adding any DTD or XML definitions.
> 2. Allow future doctypes.
> 
> However after discussing it more thoroughly at our meeting today, we are
> going to create a field on topics to specify the doctype and use that to
> return the correct doctype for those endpoints. However that will be a bit
> more down the track (but still not worth supporting in the Topic Tool).

Right.

> The other reason for the patch is to allow topic Revisions to be pulled and
> keep the topic ID. Eg
> 
> /topic/get/xml/32/r/19039/xml

I opened a bug for supporting this in the topic tool but as it turns out that style of URL already exports correctly assuming the user's topic.conf is setup to export from pressgang.

I did however notice that if you try and pull HTML using this mechanism it doesn't seem to work?

/topic/get/html/32/r/19039/html

JSON works as expected:

/topic/get/json/32/r/19039/

(In reply to comment #4)
> > The other reason for the patch is to allow topic Revisions to be pulled and
> > keep the topic ID. Eg
> > 
> > /topic/get/xml/32/r/19039/xml
> 
> I opened a bug for supporting this in the topic tool but as it turns out
> that style of URL already exports correctly assuming the user's topic.conf
> is setup to export from pressgang.
> 
> I did however notice that if you try and pull HTML using this mechanism it
> doesn't seem to work?
> 
> /topic/get/html/32/r/19039/html
> 
> JSON works as expected:
> 
> /topic/get/json/32/r/19039/

Yeah, the html revision is currently bugged (see Bug #834130). In saying that though, the bug provides no details. The cause is due to a mapping issue with envers, that we haven't been able to find a suitable fix for yet. The other reason is that those endpoints are likely to disappear once the new GUI is released, as it renders on the client side similar to Josh's app.

As for the support I was aware that it supported that syntax but what about the following:

/topic/get/xml/32/r/299099/xml

/topic/get/xml/2801/r/299099/xml

From my knowledge (or last time i looked at the code) you would end up with two copies of the later topic (one file). The above can happen when changes are made by the system as it does them in bulk. ie removing a tag, spelling errors, etc...

(In reply to comment #5)
> As for the support I was aware that it supported that syntax but what about
> the following:
> 
> /topic/get/xml/32/r/299099/xml
> 
> /topic/get/xml/2801/r/299099/xml
> 
> From my knowledge (or last time i looked at the code) you would end up with
> two copies of the later topic (one file). The above can happen when changes
> are made by the system as it does them in bulk. ie removing a tag, spelling
> errors, etc...

I don't see how you came to this conclusion? The export path for URLs in this format includes the topic identifier so it ends up being:

./topics/32/r/299099.xml

and

./topics/2801/r/299099.xml

As opposed to:

./topics/32.xml

and

./topics/2801.xml

If no revision was specified.

(It should be noted this behaviour is unintentional but nonetheless functional without gutting the export logic - which is an absolute mess - to bolt on proper understanding of yet another URL format)

Well in that case there is no issue. The last time I glanced at it, I was fairly sure it just checked if the last part was /xml. If it was then it got the id before that and made the file <ID>.xml in the topics directory.

Sorry for the misunderstanding.

(In reply to comment #8)
> Well in that case there is no issue. The last time I glanced at it, I was
> fairly sure it just checked if the last part was /xml. If it was then it got
> the id before that and made the file <ID>.xml in the topics directory.
> 
> Sorry for the misunderstanding.

Sort of, it uses the trailing /xml to determine that this must be a pressgang URI (because the topic tool ones from SVN end in .xml). 

It then blindly replaces the /xml suffix with .xml when choosing the local file name and saves the result of the HTTP request (to the original unmodified URI that was found) there. 

Topic tool doesn't currently attempt to understand/interpret topic identifiers because that is a completely different way of driving topics to what it was original built for (which was where the URI effectively contained some of the metadata and taxonomy info that made the topic unique without having an ID).