Difference between revisions of "Talk:PubMan Web Syndication Feeds"

From MPDLMediaWiki
Jump to navigation Jump to search
Line 19: Line 19:
==Implementation==
==Implementation==


*must the structured export manager be redesigned to deal with feed information?
* must the structured export manager be redesigned to deal with feed information?
**the idea is - this to be done in SyndicationManager and the structured export manager to only deal with feed-entries transformation i.e. like mapping to any metadata format --[[User:Natasab|Natasa]] 14:00, 13 November 2008 (UTC)
** the idea is - this to be done in SyndicationManager and the structured export manager to only deal with feed-entries transformation i.e. like mapping to any metadata format --[[User:Natasab|Natasa]] 14:00, 13 November 2008 (UTC)
***agree --[[User:Makarenko|Makarenko]] 14:39, 13 November 2008 (UTC)
*** agree --[[User:Makarenko|Makarenko]] 14:39, 13 November 2008 (UTC)
**StructuredExportManager should distinguish the context (e.g. Faces, PubMan, VIRR) to be able to apply correct transformations since MD sets are different for applications. Possible solutions:  
** StructuredExportManager should distinguish the context (e.g. Faces, PubMan, VIRR) to be able to apply correct transformations since MD sets are different for applications. Possible solutions:  
*** XSLT parses the item list and applies appropriate transformation for the item
*** XSLT parses the item list and applies appropriate transformation for the item
:: ''Advantages'': the only XSLT should be changed and not the service.
**** ''Advantages'': the only XSLT should be changed and not the service.
:: ''Disadvantages'': a) lack of functionality for string processing in XPATH (but, probably, enough for the purpose); b) no way to use ROME
****''Disadvantages'': a) lack of functionality for string processing in XPATH (but, probably, enough for the purpose); b) no way to use ROME
*** move transformation functionality to ROME but not to the XSLT
*** move transformation functionality from XSLT to the ROME
:: ''Advantages'': a) simple and standardized approach to generate WSF all supported formats; b) JBOSS integration,
**** ''Advantages'': a) simple and standardized approach to generate WSF of '''all supported formats''', b) java string processing, c) fast development, d) JBOSS integration  
:: ''Disadvantages'': StructuredExportManager should be redesigned to adopt ROME
**** ''Disadvantages'': StructuredExportManager should be redesigned to adopt ROME

Revision as of 15:33, 13 November 2008

Feed for search results[edit]

  • each advanced search for the logged in user
Question: Why restricting this functionality to logged in users? --Inga 14:41, 17 September 2008 (UTC)
Vlad : Agree, can be extended for the case.

Naming[edit]

feedermanager sounds somewhat weird to my ears. wouldn't syndication_manager be better? Robert 11:21, 23 September 2008 (UTC)


Interfaces[edit]

Implementation[edit]

  • must the structured export manager be redesigned to deal with feed information?
    • the idea is - this to be done in SyndicationManager and the structured export manager to only deal with feed-entries transformation i.e. like mapping to any metadata format --Natasa 14:00, 13 November 2008 (UTC)
      • agree --Makarenko 14:39, 13 November 2008 (UTC)
    • StructuredExportManager should distinguish the context (e.g. Faces, PubMan, VIRR) to be able to apply correct transformations since MD sets are different for applications. Possible solutions:
      • XSLT parses the item list and applies appropriate transformation for the item
        • Advantages: the only XSLT should be changed and not the service.
        • Disadvantages: a) lack of functionality for string processing in XPATH (but, probably, enough for the purpose); b) no way to use ROME
      • move transformation functionality from XSLT to the ROME
        • Advantages: a) simple and standardized approach to generate WSF of all supported formats, b) java string processing, c) fast development, d) JBOSS integration
        • Disadvantages: StructuredExportManager should be redesigned to adopt ROME