EPData XML Representation - Revision history

Kgoetz: add category data objects

2018-09-12T00:00:29Z

add category data objects

← Older revision		Revision as of 00:00, 12 September 2018
Line 1:		Line 1:
	[[Category:~~Developer~~]]		[[Category:Contribute]]
			[[Category:Data Objects]]

	=== Specification ===		=== Specification ===

Kgoetz: add categories

2018-08-30T06:42:27Z

add categories

← Older revision		Revision as of 06:42, 30 August 2018
Line 1:		Line 1:
			[[Category:Developer]]
	=== Specification ===		=== Specification ===

Tdb01r: /* Example with Files Embedded */

2011-12-09T15:57:27Z

Example with Files Embedded

← Older revision		Revision as of 15:57, 9 December 2011
Line 88:		Line 88:
	=== Example with Files Embedded ===		=== Example with Files Embedded ===

			<source lang="xml">
	Content-Type: application/vnd.eprints.data+xml; charset="utf-8"; files=base64		Content-Type: application/vnd.eprints.data+xml; charset="utf-8"; files=base64

	~~<source lang="xml">~~
	<?xml version='1.0' encoding='utf-8'?>		<?xml version='1.0' encoding='utf-8'?>
	<eprints xmlns='http://eprints.org/ep2/data/2.0'>		<eprints xmlns='http://eprints.org/ep2/data/2.0'>

Tdb01r: /* Example with Files Embedded */

2011-12-09T15:57:05Z

Example with Files Embedded

← Older revision		Revision as of 15:57, 9 December 2011
Line 87:		Line 87:

	=== Example with Files Embedded ===		=== Example with Files Embedded ===

			Content-Type: application/vnd.eprints.data+xml; charset="utf-8"; files=base64

	<source lang="xml">		<source lang="xml">

Tdb01r: /* Example with Files Embedded */

2011-12-09T15:56:02Z

Example with Files Embedded

← Older revision		Revision as of 15:56, 9 December 2011
Line 88:		Line 88:
	=== Example with Files Embedded ===		=== Example with Files Embedded ===

	<~~nowiki~~>		<source lang="xml">
	<?xml version='1.0' encoding='utf-8'?>		<?xml version='1.0' encoding='utf-8'?>
	<eprints xmlns='http://eprints.org/ep2/data/2.0'>		<eprints xmlns='http://eprints.org/ep2/data/2.0'>
Line 161:		Line 161:
	<date>2011-05-28</date>		<date>2011-05-28</date>
	</eprint>		</eprint>
	</eprints></~~nowiki~~>		</eprints>
			</source>

	=== IETF-Registration Draft ===		=== IETF-Registration Draft ===

Tdb01r: /* Example */

2011-12-09T15:55:28Z

Example

← Older revision		Revision as of 15:55, 9 December 2011
Line 20:		Line 20:
	=== Example ===		=== Example ===

	<~~nowiki~~>		<source lang="xml">
	Content-Type: application/vnd.eprints.data+xml; charset="utf-8"		Content-Type: application/vnd.eprints.data+xml; charset="utf-8"

Line 72:		Line 72:
	</subjects>		</subjects>
	<full_text_status>public</full_text_status>		<full_text_status>public</full_text_status>
	<abstract>" '^M		<abstract>" '
	^M
	\ /^M		\ /
	^M
	Aut do och Чем modi. Φακέλους et Scholl itaque αρέσει rerum tenetur हुएआदि. Similque команда voluptas или quidem schaddreg voluptatum ίδιο. Nulla animi νέα συνηθίζουν d'Loft inventore quis.^M		Aut do och Чем modi. Φακέλους et Scholl itaque αρέσει rerum tenetur हुएआदि. Similque команда voluptas или quidem schaddreg voluptatum ίδιο. Nulla animi νέα συνηθίζουν d'Loft inventore quis.
	^M
	Expedita praesentium σημαίνει Нее rei sed et стратегические. Doloribus alias प्रा ea reiciendis Frot. Molestiae αντιλήφθηκαν μου enim. Tenetur πως отнимет во. Nihil voluptatum nobis dolorum laudantium cum Jo τι.</abstract>		Expedita praesentium σημαίνει Нее rei sed et стратегические. Doloribus alias प्रा ea reiciendis Frot. Molestiae αντιλήφθηκαν μου enim. Tenetur πως отнимет во. Nihil voluptatum nobis dolorum laudantium cum Jo τι.</abstract>
	<date>1961</date>		<date>1961</date>
Line 84:		Line 84:
	</eprint>		</eprint>
	</eprints>		</eprints>
	</~~nowiki~~>		</source>

	=== Example with Files Embedded ===		=== Example with Files Embedded ===

Tdb01r at 15:53, 9 December 2011

2011-12-09T15:53:59Z

← Older revision		Revision as of 15:53, 9 December 2011
Line 1:		Line 1:
	~~Warning! This is just a place-holder while I investigate whether its practical to register a MIME-type.~~

	=== Specification ===		=== Specification ===

Tdb01r: /* IETF-Registration Draft */

2011-06-17T11:47:56Z

IETF-Registration Draft

← Older revision		Revision as of 11:47, 17 June 2011
Line 200:		Line 200:
	No executable or active content is defined.		No executable or active content is defined.

	No integrity features are ~~provided~~ by the media type, with the exception that where files are embedded and checksums are provided the ingesting service should verify the decoded file content against its checksum before further processing those files.		No integrity features are defined by the media type, with the exception that where files are embedded and checksums are provided the ingesting service should verify the decoded file content against its checksum before further processing those files.

	No explicit privacy features are ~~provided~~ by the media type but may be provided on an implementation-specific basis.		No explicit privacy features are defined by the media type but privacy-relevant metadata may be provided on an implementation-specific basis.

	~~Embedded~~ files may contain executable or malicious content. If file content is decoded care should be taken before any further processing or publication by ~~e.g.~~ applying a virus-checker.		If files are embedded they may contain executable and/or malicious content. If file content is decoded care should be taken before any further processing or publication by for example applying a virus-checker.

	Record identifiers may be included that either intentionally or unintentionally conflict with existing identifiers in a consuming system. Care must be taken that existing records are not unintentionally overwritten by ~~either~~ assigning new identifiers on ingest or ensuring ~~that ingested data~~ is ~~trusted to update~~ existing records.		Record identifiers may be included that either intentionally or unintentionally conflict with existing identifiers in a consuming system. Care must be taken that existing records are not unintentionally overwritten. This can be achieved by assigning new identifiers on ingest or by ensuring the current user is the owner of the existing records.

	~~References to files by URL may be included.~~ During ingest the system may choose to retrieve ~~these~~ files ~~and include them in the resulting record~~. If the file is located on the Web (http: or https:) the system should exercise caution to avoid being used by untrusted users as a means of circumventing host-based restrictions. URLs pointing to the local file-system must be ignored for any untrusted sources.		During ingest the system may choose to retrieve files included by-URL reference. If the file is located on the Web (http: or https:) the system should exercise caution to avoid being used by untrusted users as a means of circumventing host-based restrictions. URLs pointing to the local file-system must be ignored for any untrusted sources.


Line 235:		Line 235:

	Intended usage : Limited Use		Intended usage : Limited Use
	XML serialisation of EPrints Data (or "EPData") for the import/export of the complete record. This is used e.g. for ingesting the results of XSL transforms from standardised XML formats. The mime-type is necessary to support correct content-type negotiation when using the EPrints REST interface although the client will require knowledge of the instance's database scheme.		XML serialisation of EPrints Data (or "EPData") for the import/export of the complete record. This is used e.g. for ingesting the results of XSL
			transforms from standardised XML formats. The mime-type is necessary to support correct content-type negotiation when using the EPrints REST interface although the client will require knowledge of the instance's database scheme.

	Author/Change controller : EPrints.org http://www.eprints.org/		Author/Change controller : EPrints.org http://www.eprints.org/

Tdb01r: /* IETF-Registration Draft */

2011-06-17T11:38:47Z

IETF-Registration Draft

← Older revision		Revision as of 11:38, 17 June 2011
Line 235:		Line 235:

	Intended usage : Limited Use		Intended usage : Limited Use
	XML serialisation of EPrints Data (or "EPData") for the import/export of the complete record. This is used e.g. for ingesting the results of XSL		XML serialisation of EPrints Data (or "EPData") for the import/export of the complete record. This is used e.g. for ingesting the results of XSL transforms from standardised XML formats. The mime-type is necessary to support correct content-type negotiation when using the EPrints REST interface although the client will require knowledge of the instance's database scheme.
	transforms from standardised XML formats. The mime-type is necessary to support correct content-type negotiation when using the EPrints REST interface although the client will require knowledge of the instance's database scheme.

	Author/Change controller : EPrints.org http://www.eprints.org/		Author/Change controller : EPrints.org http://www.eprints.org/

Tdb01r: /* IETF-Registration Draft */

2011-06-17T11:38:27Z

IETF-Registration Draft

← Older revision		Revision as of 11:38, 17 June 2011
Line 188:		Line 188:
	Indicates that file content has been embedded in the response XML. This is used during content-negotiation to allow the client to request file content be included. If the client does not have permission to access file content this parameter will be ignored.		Indicates that file content has been embedded in the response XML. This is used during content-negotiation to allow the client to request file content be included. If the client does not have permission to access file content this parameter will be ignored.

	"base64" is the only supported value and indicates that file content has been embedded using base64 ~~encoded~~. If the parameter is empty or any other value the parameter meaning is undefined (in a response) or should be ignored (during content negotiation).		"base64" is the only supported value and indicates that file content has been embedded using base64 encoding. If the parameter is empty or any other value the parameter meaning is undefined (in a response) or should be ignored (during content negotiation).


Line 206:		Line 206:
	Embedded files may contain executable or malicious content. If file content is decoded care should be taken before any further processing or publication by e.g. applying a virus-checker.		Embedded files may contain executable or malicious content. If file content is decoded care should be taken before any further processing or publication by e.g. applying a virus-checker.

	~~Identifiers~~ may be included that either intentionally or unintentionally conflict with existing identifiers in a consuming system. Care must be taken that existing records are not unintentionally overwritten by either assigning new identifiers on ingest or ensuring that ingested data is trusted to update existing records.		Record identifiers may be included that either intentionally or unintentionally conflict with existing identifiers in a consuming system. Care must be taken that existing records are not unintentionally overwritten by either assigning new identifiers on ingest or ensuring that ingested data is trusted to update existing records.

	References to files by URL may be included. During ingest the system may choose to retrieve these files and include them in the resulting record. If the ~~URL~~ is a Web ~~location~~ (http: or https:) the system should exercise caution to avoid being ~~poisoned by large files or~~ by untrusted users as a means of circumventing host-based restrictions. If the ~~URL points to a~~ local file-system ~~location (or other scheme) this~~ must be ignored for any untrusted sources.		References to files by URL may be included. During ingest the system may choose to retrieve these files and include them in the resulting record. If the file is located on the Web (http: or https:) the system should exercise caution to avoid being used by untrusted users as a means of circumventing host-based restrictions. URLs pointing to the local file-system must be ignored for any untrusted sources.


Line 236:		Line 236:
	Intended usage : Limited Use		Intended usage : Limited Use
	XML serialisation of EPrints Data (or "EPData") for the import/export of the complete record. This is used e.g. for ingesting the results of XSL		XML serialisation of EPrints Data (or "EPData") for the import/export of the complete record. This is used e.g. for ingesting the results of XSL
	transforms from standardised XML formats. The mime-type is necessary to		transforms from standardised XML formats. The mime-type is necessary to support correct content-type negotiation when using the EPrints REST interface although the client will require knowledge of the instance's database scheme.
	support correct content-type negotiation when using the EPrints REST
	interface although the client will require knowledge of the instance's
	database scheme.

	Author/Change controller : EPrints.org http://www.eprints.org/		Author/Change controller : EPrints.org http://www.eprints.org/