Bug 869129 - RFE: Add Doctype Declartions to the returned XML.
RFE: Add Doctype Declartions to the returned XML.
Status: CLOSED CURRENTRELEASE
Product: PressGang CCMS
Classification: Community
Component: REST-API (Show other bugs)
1.0
Unspecified Unspecified
unspecified Severity unspecified
: ---
: ---
Assigned To: pressgang-ccms-dev
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2012-10-23 02:15 EDT by Lee Newson
Modified: 2015-09-27 22:20 EDT (History)
1 user (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2013-07-01 19:53:19 EDT
Type: Bug
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)

  None (edit)
Comment 2 Stephen Gordon 2012-11-23 09:00:33 EST
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
Comment 3 Lee Newson 2012-11-25 20:44:25 EST
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.
Comment 4 Stephen Gordon 2012-11-28 11:09:29 EST
(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/
Comment 5 Lee Newson 2012-11-28 15:47:51 EST
(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...
Comment 6 Stephen Gordon 2012-11-28 16:30:57 EST
(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.
Comment 7 Stephen Gordon 2012-11-28 16:40:10 EST
(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)
Comment 8 Lee Newson 2012-11-28 16:41:50 EST
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.
Comment 9 Stephen Gordon 2012-11-28 16:55:13 EST
(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).

Note You need to log in before you can comment on or make changes to this bug.