remove newlines

Author: edgchen1

docs/execution-providers/plugin-ep-libraries/index.md

@@ -6,7 +6,6 @@ nav_order: 17
 ---
 
 # Plugin Execution Provider Libraries
-
 An ONNX Runtime Execution Provider (EP) executes model operations on one or more hardware accelerators (e.g., GPU, NPU, etc.). ONNX Runtime provides a variety of built-in EPs, such as the default CPU EP. To enable further extensibility, ONNX Runtime supports user-defined plugin EP libraries that an application can register with ONNX Runtime for use in an ONNX Runtime inference session.
 
 This section provides a reference for plugin EP libraries.

docs/execution-providers/plugin-ep-libraries/packaging.md

@@ -7,13 +7,11 @@ nav_order: 3
 ---
 
 # Plugin Execution Provider Library Packaging Guidance
-
 {: .no_toc }
 
 This page provides guidance for ONNX Runtime plugin EP implementers to consider with regards to packaging for a plugin EP.
 
 ## Contents
-
 {: .no_toc }
 
 * TOC placeholder
@@ -22,17 +20,14 @@ This page provides guidance for ONNX Runtime plugin EP implementers to consider
 ## General Guidance
 
 ### Usage
-
 Note: Generally, when referring to the ORT API, we will refer to the C API functions. Equivalents should exist for other language bindings that support plugin EP usage.
 
 #### Manual EP Library Registration
-
 Users are expected to call [`OrtApi::RegisterExecutionProviderLibrary()`](https://onnxruntime.ai/docs/api/c/struct_ort_api.html#a7c8ea74a2ee54d03052f3d7cd1e1335d) to register the plugin EP library. Then, they may either choose to use the auto EP selection mechanism or manually call [`OrtApi::SessionOptionsAppendExecutionProvider_V2()`](https://onnxruntime.ai/docs/api/c/struct_ort_api.html#a285a5da8c9a63eff55dc48e4cf3b56f6) to explicitly use the plugin EP.
 
 ### Structure
 
 #### Contents
-
 A plugin EP package should contain the plugin EP shared library file and any other files that need to be distributed with it.
 
 A plugin EP package should NOT contain the ORT shared library or other core ORT libraries (e.g., onnxruntime.dll or libonnxruntime.so). Users should obtain the ORT library separately, most likely via installing the separate ONNX Runtime package.
@@ -42,7 +37,6 @@ A plugin EP package should have no need to depend on the separate ONNX Runtime p
 #### Additional Information to Provide
 
 ##### Library Path
-
 There should be a way to get the package's plugin EP library path. The user will need the plugin EP library path to call `OrtApi::RegisterExecutionProviderLibrary()`.
 
 For example, the package may provide a helper function that returns the path to the plugin EP library. The recommended name for this helper function is "get library path".
@@ -53,7 +47,6 @@ There should be a way to get the plugin EP name(s) provided by the package. The
 For example, the plugin EP name(s) may be well-documented or made available with a helper function provided by the package. The recommended name for a helper function returning all EP names is "get EP names". Additionally, if there is only one EP name, a helper function returning the single value named "get EP name" may be provided for convenience.
 
 #### Package Naming
-
 The name of the package should indicate that the package contains a plugin EP and be distinguishable from other ORT packages.
 
 For example, this may be done by using a special prefix or suffix.
@@ -63,23 +56,20 @@ For example, this may be done by using a special prefix or suffix.
 ### PyPI
 
 #### Package Naming
-
 The prefix "onnxruntime-ep" can be used to identify a plugin EP.
 
 The suggested package naming convention is "onnxruntime-ep-\<EP identifier\>".
 
 For example, "onnxruntime-ep-contoso-ai".
 
 #### Helper Functions
-
 The package should provide helper function `get_library_path()` to get the EP library path.
 
 The package should provide helper function `get_ep_names()` to get the EP name(s).
 
 The package may provide helper function `get_ep_name()` to get the single EP name if there is just one.
 
 #### Usage example
-
 ```python
 import onnxruntime as ort
 import onnxruntime_ep_contoso_ai as contoso_ep
@@ -133,15 +123,13 @@ ort.unregister_execution_provider_library(ep_registration_name)
 ### NuGet
 
 #### Package Naming
-
 NuGet packages may use a reserved ID prefix.
 
 The suggested package naming convention is "\<Vendor prefix\>.ML.OnnxRuntime.\<EP identifier\>.EP".
 
 For example, "Contoso.ML.OnnxRuntime.ContosoAI.EP".
 
 #### Helper Functions
-
 The package should provide helper function `GetLibraryPath()` to get the EP library path.
 
 The package should provide helper function `GetEpNames()` to get the EP name(s).

docs/execution-providers/plugin-ep-libraries/testing.md

@@ -7,32 +7,27 @@ nav_order: 2
 ---
 
 # Plugin Execution Provider Library Testing Guidance
-
 {: .no_toc }
 
 A plugin EP is responsible for ensuring that its implementation behaves correctly. This includes interacting with ONNX Runtime in the expected way as documented by the plugin EP API. It also includes the operator-level behavior as specified by the operator specification, e.g., from the ONNX standard.
 
 ## Contents
-
 {: .no_toc }
 
 * TOC placeholder
 {:toc}
 
 ## EP unit testing
-
 Plugin EP implementations are expected to have their own unit tests.
 
 ### Operator-level testing utility provided by ONNX Runtime
-
 ONNX Runtime has existing unit tests that validate an EP's op implementation. These tests are located in the unit test program `onnxruntime_provider_test`. This program supports usage with a dynamically specified plugin EP.
 
 In particular, unit tests utilizing the `onnxruntime::test::OpTester` or `onnxruntime::test::ModelTester` classes can also be run with a plugin EP.
 
 Plugin EP implementers may use this test program to help test their plugin EP if desired. The rest of this section explains how to do this.
 
 #### Building
-
 Build the onnxruntime shared library and the `onnxruntime_provider_test` target from source.
 ```
 cd <onnxruntime repo>
@@ -43,7 +38,6 @@ cd <onnxruntime repo>
 The onnxruntime shared library and `onnxruntime_provider_test` will be available in the binary output directory.
 
 #### Running
-
 `onnxruntime_provider_test` supports the standard GoogleTest arguments. E.g., `--gtest_filter` can be used to run particular tests of interest.
 
 Importantly, it supports configuration of a dynamically specified plugin EP through the environment variable `ORT_UNIT_TEST_MAIN_DYNAMIC_PLUGIN_EP_CONFIG_JSON`. The configuration value should be specified as a JSON string.
@@ -67,7 +61,6 @@ As an alternative to `selected_ep_name`, `selected_ep_device_indices` may be set
 Optionally, `default_ep_options` may be set to specify EP-specific options as string key value pairs.
 
 ## EP integration testing and model testing
-
 There are a number of APIs that a plugin EP will implement to interact with ONNX Runtime. Although conformance tests at the EP API level were considered, they were not deemed to be that useful yet. Currently, it is expected that the integration with ONNX Runtime can be meaningfully tested using high level tests that run an entire model.
 
 Plugin EPs may vary significantly from one to another in terms of capability, whether it is optional feature support or operator support. Therefore, it is expected that plugin EPs will have a set of models that are most relevant to them and that these models can be used for testing.