MCP Conversion Specs ONVIF™ 2025-11-13 0.0-skeleton 2025-11-13 Rebuild Skeleton structure created from scratch prior to incremental content reintroduction.

This specification defines the mandatory and complete mapping rules for converting XML Schema Definition (XSD) types into JSON Schema (Draft 7) type definitions. Conformance: All implementations claiming conformance to this specification MUST follow these rules exactly. Any deviation will produce incompatible output. Version: 2.1 Date: November 13, 2025 Scope: Complete XSD type system mapping to JSON Schema Status: Prescriptive (all implementations MUST conform)

Version Date Changes 2.1 2025-11-13 Added Section 6.4 Type Metadata Preservation (title and x-onvif-type fields) to preserve semantic type information in generated JSON Schemas 2.0 2025-11-13 Split from ONVIF_TO_MCP_CONVERSION_SPEC v1.3; focus on XSD→JSON Schema mapping only 1.3 2025-11-12 Made specification prescriptive; added mandatory format field mapping 1.0 2025-11-11 Initial specification with full XSD type mapping

This specification covers the conversion of XSD type definitions to JSON Schema, including: Primitive type mapping (strings, numbers, booleans, dates, binary) Complex type structures (sequences, choices, attributes) Simple type restrictions (enumerations, patterns, ranges) Type inheritance (extension and restriction) Array handling and cardinality Circular reference detection and handling

XSD types are referenced using namespace prefixes: xs: - XML Schema primitives (e.g., xs:string, xs:int, xs:dateTime) Custom namespaces - Application-specific types (e.g., tt:VideoSource, tptz:PTZVector)

All conversions MUST produce valid JSON Schema Draft 7 output with: type field specifying the JSON type properties for object structures required array for mandatory fields Appropriate constraints (minimum, maximum, pattern, enum, etc.) Format hints for semantic types (format, contentEncoding)

Completeness: All XSD types MUST map to valid JSON Schema Validation: Generated schemas MUST enable runtime parameter validation Clarity: Complex types MUST be fully expanded to show structure Standards: MUST follow JSON Schema Draft 7 specification Semantics: MUST preserve type constraints and validation rules

XSD TypeJSON SchemaNotesxs:string{"type":"string"}UTF-8 textxs:token{"type":"string"}Whitespace-normalized stringxs:normalizedString{"type":"string"}Line breaks and tabs normalized to spacesxs:anyURI{"type":"string","format":"uri"}URI reference (absolute or relative)xs:QName{"type":"string"}Qualified name: prefix:localNamexs:NOTATION{"type":"string"}Notation type for declaring notation attributes Format Field Rule: XSD TypeJSON Schema FieldNotesxs:anyURIformat: "uri"Populate format to convey URI semantic

XSD TypeJSON SchemaNotesxs:integer{"type":"integer"}Arbitrary precisionxs:int{"type":"integer"}32-bit signedxs:long{"type":"integer"}64-bit signedxs:short{"type":"integer"}16-bit signedxs:byte{"type":"integer"}8-bit signedxs:unsignedInt{"type":"integer","minimum":0}32-bit unsignedxs:unsignedLong{"type":"integer","minimum":0}64-bit unsignedxs:unsignedShort{"type":"integer","minimum":0}16-bit unsignedxs:unsignedByte{"type":"integer","minimum":0}8-bit unsignedxs:positiveInteger{"type":"integer","minimum":1}Positive onlyxs:nonNegativeInteger{"type":"integer","minimum":0}Zero or positivexs:negativeInteger{"type":"integer","maximum":-1}Negative onlyxs:nonPositiveInteger{"type":"integer","maximum":0}Zero or negativexs:float{"type":"number"}IEEE 754 singlexs:double{"type":"number"}IEEE 754 doublexs:decimal{"type":"number"}Arbitrary precision

XSD TypeJSON SchemaValid Valuesxs:boolean{"type":"boolean"}true, false

XSD TypeJSON SchemaNotesxs:dateTime{"type":"string","format":"date-time"}ISO 8601 date-time (e.g., 2025-11-13T14:30:00Z)xs:date{"type":"string","format":"date"}ISO 8601 date (e.g., 2025-11-13)xs:time{"type":"string","format":"time"}ISO 8601 time (e.g., 14:30:00)xs:duration{"type":"string","format":"duration"}ISO 8601 duration (e.g., PT1H30M) Format Field Rules: XSD TypeRequired JSON Schema FormatExamplexs:dateTime"date-time"2025-11-13T14:30:00Zxs:date"date"2025-11-13xs:time"time"14:30:00xs:duration"duration"PT1H30M

XSD TypeJSON SchemaNotesxs:base64Binary{"type":"string","contentEncoding":"base64"}Base64-encoded binary dataxs:hexBinary{"type":"string"}Hexadecimal-encoded binary data Encoding Rule: XSD TypeJSON Schema EncodingNotesxs:base64BinarycontentEncoding: "base64"Set contentEncoding to indicate base64-encoded dataxs:hexBinary(none)No standard JSON Schema field; represented as plain string

XSD TypeJSON SchemaNotesxs:anyType{}No constraints (any valid JSON)xs:anySimpleType{}Any simple value (string, number, boolean)

XSD complex types define objects with attributes and child elements. They convert to JSON Schema objects: { "type": "object", "properties": { /* ... */ }, "required": [ /* ... */ ] }

XSD attributes become JSON Schema properties. Attribute metadata controls conversion: <xs:complexType name="VideoSource"> <xs:attribute name="token" type="tt:ReferenceToken" use="required"/> <xs:attribute name="Framerate" type="xs:float" use="optional"/> </xs:complexType> Converts to: { "type": "object", "properties": { "token": {"type": "string", "maxLength": 64}, "Framerate": {"type": "number"} }, "required": ["token"] } Attribute Mapping Rules: Attribute ConditionJSON Schema Actionuse="required"Add attribute name to required arrayuse="optional" or omittedRepresent as optional property (omit from required)Attribute nameBecomes property keyAttribute typeResolve and convert per primitive/simple/complex rules

<xs:sequence> defines ordered child elements. In JSON Schema, order is not enforced, so sequences become properties: <xs:complexType name="PTZSpeed"> <xs:sequence> <xs:element name="PanTilt" type="tt:Vector2D" minOccurs="0"/> <xs:element name="Zoom" type="tt:Vector1D" minOccurs="0"/> </xs:sequence> </xs:complexType> Converts to: { "type": "object", "properties": { "PanTilt": { "type": "object", "properties": { "x": {"type": "number"}, "y": {"type": "number"} }, "required": ["x", "y"] }, "Zoom": { "type": "object", "properties": { "x": {"type": "number"} }, "required": ["x"] } }, "required": [] } Sequence Mapping Rules: XSD OccurrenceConditionJSON Schema RepresentationminOccurs="0"Element optionalProperty omitted from requiredminOccurs="1" (default)Element mandatoryProperty name added to requiredmaxOccurs="1" (default)Single instanceSingle property valuemaxOccurs>1Multiple bounded{"type":"array","maxItems":N}maxOccurs="unbounded"Multiple unbounded{"type":"array"} (no maxItems)

Elements can have inline (anonymous) complex type definitions instead of references: <xs:element name="Configuration"> <xs:complexType> <xs:sequence> <xs:element name="Name" type="xs:string"/> <xs:element name="UseCount" type="xs:int"/> </xs:sequence> </xs:complexType> </xs:element> Converts to: { "type": "object", "properties": { "Name": {"type": "string"}, "UseCount": {"type": "integer"} }, "required": ["Name", "UseCount"] } Inline Type Rule: Inline complex types are expanded directly in place.

<xs:choice> represents mutually exclusive options. Convert to anyOf: <xs:complexType name="MediaUri"> <xs:choice> <xs:element name="Uri" type="xs:anyURI"/> <xs:element name="InvalidAfterConnect" type="xs:boolean"/> <xs:element name="InvalidAfterReboot" type="xs:boolean"/> </xs:choice> </xs:complexType> Converts to: { "anyOf": [ { "type": "object", "properties": {"Uri": {"type": "string", "format": "uri"}}, "required": ["Uri"] }, { "type": "object", "properties": {"InvalidAfterConnect": {"type": "boolean"}}, "required": ["InvalidAfterConnect"] }, { "type": "object", "properties": {"InvalidAfterReboot": {"type": "boolean"}}, "required": ["InvalidAfterReboot"] } ] } Choice Mapping Rules: AspectRuleMutual exclusivityRepresent with anyOfEach branchSeparate object schema variantProperty wrappingChoice element becomes property inside its variant objectRequired fieldChosen element listed in required for that variant

<xs:all> is similar to <xs:sequence> but elements can appear in any order: <xs:complexType name="Capabilities"> <xs:all> <xs:element name="XAddr" type="xs:anyURI" minOccurs="0"/> <xs:element name="RuleSupport" type="xs:boolean" minOccurs="0"/> </xs:all> </xs:complexType> Converts to: { "type": "object", "properties": { "XAddr": {"type": "string", "format": "uri"}, "RuleSupport": {"type": "boolean"} }, "required": [] } All Elements Rule: Treat similar to xs:sequence (JSON has no ordering).

<xs:extension> adds fields to a base type. Implementations MUST inline both base and extension properties: <xs:complexType name="PTZConfiguration"> <xs:complexContent> <xs:extension base="tt:ConfigurationEntity"> <xs:sequence> <xs:element name="NodeToken" type="tt:ReferenceToken"/> <xs:element name="DefaultPTZSpeed" type="tt:PTZSpeed" minOccurs="0"/> </xs:sequence> </xs:extension> </xs:complexContent> </xs:complexType> <!-- Base type --> <xs:complexType name="ConfigurationEntity"> <xs:attribute name="token" type="tt:ReferenceToken" use="required"/> <xs:attribute name="Name" type="xs:string" use="required"/> </xs:complexType> Converts to (base properties + extension properties): { "type": "object", "properties": { "token": {"type": "string", "maxLength": 64}, "Name": {"type": "string"}, "NodeToken": {"type": "string", "maxLength": 64}, "DefaultPTZSpeed": { "type": "object", "properties": { /* ... */ } } }, "required": ["token", "Name", "NodeToken"] } Extension Rule: Merge base type properties with extension properties in a single flat object.

<xs:restriction> limits or redefines a base type: <xs:complexType name="IntRange"> <xs:complexContent> <xs:restriction base="xs:anyType"> <xs:sequence> <xs:element name="Min" type="xs:int"/> <xs:element name="Max" type="xs:int"/> </xs:sequence> </xs:restriction> </xs:complexContent> </xs:complexType> Restriction Rule: Use the restricted definition, ignore the base type (restriction fully replaces base).

Mixed content types allow text and elements. Rarely used in ONVIF: <xs:complexType name="Description" mixed="true"> <xs:sequence> <xs:element name="Link" type="xs:anyURI" minOccurs="0"/> </xs:sequence> </xs:complexType> Mixed Content Rule: Treat as object with properties (ignore text content capability in JSON Schema).

XSD enumerations define allowed values. Convert to JSON Schema enum: <xs:simpleType name="AutoFocusMode"> <xs:restriction base="xs:string"> <xs:enumeration value="AUTO"/> <xs:enumeration value="MANUAL"/> </xs:restriction> </xs:simpleType> Converts to: { "type": "string", "enum": ["AUTO", "MANUAL"] } Enumeration Rules: Step / AspectDescriptionJSON Schema ImpactValue extractionCollect each <xs:enumeration value="..."/>Populate entries in enum arrayOrder preservationMaintain source orderDisplay order retained (non-functional)Base type retentionUse restriction baseSet type accordinglyNon-string enumerationsSupport numeric or other basestype may be integer, number, etc.Exact match enforcementNo additional values permittedValidator restricts to listed enum members

XSD pattern restrictions define regex constraints: <xs:simpleType name="ReferenceToken"> <xs:restriction base="xs:string"> <xs:maxLength value="64"/> </xs:restriction> </xs:simpleType> Converts to: { "type": "string", "maxLength": 64 } With regex pattern: <xs:simpleType name="DNSName"> <xs:restriction base="xs:token"> <xs:pattern value="[A-Za-z0-9\-\.]+"/> </xs:restriction> </xs:simpleType> Converts to: { "type": "string", "pattern": "^[A-Za-z0-9\\-\\.]+$" } Pattern Mapping Rules: XSD Construct / RuleJSON Schema Representation<xs:pattern value="..."/>"pattern" field with the regex valueRegex anchoringAdd ^ and $ if not present to ensure full-string matchBackslash escapingEscape backslashes for JSON: \\ becomes \\\\<xs:maxLength value="N"/>"maxLength": N<xs:minLength value="N"/>"minLength": N

XSD lists allow space-separated values of a base type: <xs:simpleType name="IntList"> <xs:list itemType="xs:int"/> </xs:simpleType> List Rule: Convert to JSON array of the item type: { "type": "array", "items": {"type": "integer"} }

XSD numeric restrictions define min/max constraints: <xs:simpleType name="FactorRange"> <xs:restriction base="xs:float"> <xs:minInclusive value="1.0"/> <xs:maxInclusive value="10.0"/> </xs:restriction> </xs:simpleType> Converts to: { "type": "number", "minimum": 1.0, "maximum": 10.0 } Numeric Constraint Mapping: XSD RestrictionJSON Schema Field<xs:minInclusive>"minimum"<xs:maxInclusive>"maximum"<xs:minExclusive>"exclusiveMinimum"<xs:maxExclusive>"exclusiveMaximum"

XSD unions allow multiple possible types: <xs:simpleType name="IntOrString"> <xs:union memberTypes="xs:int xs:string"/> </xs:simpleType> Union Rule: Convert to anyOf with each member type: { "anyOf": [ {"type": "integer"}, {"type": "string"} ] }

XSD elements with maxOccurs > 1 or maxOccurs="unbounded" become arrays: <xs:element name="Profile" type="tt:Profile" minOccurs="0" maxOccurs="unbounded"/> Converts to: { "type": "array", "items": { "type": "object", "properties": { /* Profile type expanded */ } } } Array Mapping Rules: XSD AttributeConditionJSON Schema FieldNotesmaxOccurs="unbounded"Unlimited repetitions(no maxItems)Array has no size capmaxOccurs="N"Finite repetitionsmaxItems: NUpper bound enforcedminOccurs="M"Minimum occurrencesminItems: MLower bound enforcedItem typeElement type referenceitems: { ... }Expand inline, no $ref

Bounded arrays translate both minimum and maximum constraints: <xs:element name="SupportedRules" type="xs:string" minOccurs="1" maxOccurs="100"/> Converts to: { "type": "array", "items": {"type": "string"}, "minItems": 1, "maxItems": 100 } Cardinality Constraints: XSD CombinationJSON SchemaInterpretationminOccurs=0, maxOccurs=1Single optional valueRepresent as optional property (not array)minOccurs=1, maxOccurs=1Single required valueProperty in required (not array)minOccurs=0, maxOccurs>1minItems omitted; maxItems setOptional bounded arrayminOccurs>0, maxOccurs>1minItems and maxItems setRequired bounded array meeting min constraintminOccurs=0, maxOccurs="unbounded"No minItems, no maxItemsOptional unbounded arrayminOccurs>0, maxOccurs="unbounded"minItems set; no maxItemsRequired unbounded array with minimum size

Required Strategy: All types MUST be fully expanded inline at point of use. No JSON Schema $ref is used for type references. Example - Instead of using references: { "properties": { "Speed": {"$ref": "#/definitions/PTZSpeed"} } } Implementations MUST expand inline: { "properties": { "Speed": { "type": "object", "properties": { "PanTilt": { /* expanded */ }, "Zoom": { /* expanded */ } } } } } Resolution Steps: StepDescriptionOutcomeLocateFind type definition by QNameObtain source structureClassifyDetermine primitive / simple / complexSelect mapping pathExpandRecursively inline nested typesNo remaining referencesFinalizeAdd required arrays, properties, metadataComplete inline JSON Schema object

When expanding types from different namespaces (e.g., tt:PTZVector referencing tt:Vector2D): RuleDescriptionResultLookupResolve QName via prefix to namespace and registryAccess correct type definitionRecursive expansionContinue until primitives reachedFlattened structureNamespace preservationRetain original prefix in metadata (see 6.4)Traceability retained

Circular type references (A references B, B references A) MUST be detected and handled. AspectMechanismConditionActionTrackingMaintain expansion call stackType appears twiceMark circularDepth limitMax depth = 10Depth exceededTreat as circular to prevent runaway expansionSchema outputReplace nested objectCircular detected{"type":"object","x-onvif-circular-ref":true}ContinuationStop deeper recursionCircular encounteredReturn current partial schema Example: { "type": "object", "properties": { "Parent": { "type": "object", "x-onvif-circular-ref": true } } }

Purpose: Preserve XSD type names in JSON Schema to maintain semantic meaning and readability. Implementations MUST add metadata fields to preserve original type information: FieldSourceApplicabilityNotestitleLocal name (drop prefix)All complex & simple named typesHuman-readable namex-onvif-typeFull QName (prefix:name)All complex & simple named typesEnables precise type tracking(omit)Primitives (e.g. xs:int)Primitive typesNo metadata added Application Rules: RuleDescriptionExample ImpactNo overrideDo not overwrite if field already presentExisting title keptNested expansionApply to each nested named typeVector2D inside PTZVector receives metadataPrefix retentionKeep original namespace prefix in x-onvif-typett:PTZVector Example - Complex Type: { "type": "object", "title": "PTZVector", "x-onvif-type": "tt:PTZVector", "properties": { "PanTilt": { "type": "object", "title": "Vector2D", "x-onvif-type": "tt:Vector2D", "properties": {"x": {"type": "number"}, "y": {"type": "number"}} }, "Zoom": { "type": "object", "title": "Vector1D", "x-onvif-type": "tt:Vector1D", "properties": {"x": {"type": "number"}} } }, "required": ["PanTilt"] } Example - Simple Type Restriction: { "type": "string", "title": "ReferenceToken", "x-onvif-type": "tt:ReferenceToken", "maxLength": 64 }

XSD uses minOccurs (elements) and use (attributes) to indicate requiredness. These MUST be mapped to JSON Schema required array entries. XSD ConstructConditionJSON Schema RepresentationNotesElementminOccurs="0"Property NOT listed in requiredOptional elementElementminOccurs omitted OR minOccurs="1"Property name added to requiredMandatory elementAttributeuse="optional" or omittedProperty NOT listed in requiredOptional attributeAttributeuse="required"Property name added to requiredMandatory attributeElementminOccurs>1Property name added; array may get minItemsMinimum repeats enforced

XSD elements marked nillable="true" allow explicit NULL via xsi:nil="true". In JSON Schema this MUST be represented as permitting null value in addition to the normal type. XSD AttributeJSON Schema TechniqueResult Schema FragmentNotesnillable="true"anyOf combining real type + null{"anyOf":[{"type":"string"},{"type":"null"}]}Example for string typenillable="false" or omittedUse normal mapping{"type":"string"}No null allowedComplex type nillableWrap object schema in anyOf with {"type":"null"}{"anyOf":[{"type":"object","properties":{...}},{"type":"null"}]}Preserves structure when non-null Example: { "anyOf": [ { "type": "object", "properties": {"Token": {"type": "string"}}, "required": ["Token"] }, {"type": "null"} ] }

XSD default attribute supplies a value when absent. JSON Schema does not apply defaults during validation but MAY include a default field for tooling. Implementations MUST copy default values verbatim. XSD ConstructExampleJSON Schema FieldNotesAttribute with default<xs:attribute name="Mode" type="xs:string" default="AUTO"/>"default": "AUTO"Property remains optional unless use="required"Element with default<xs:element name="Enabled" type="xs:boolean" default="true"/>"default": trueWill not auto-inject; consumer logic appliesDefault + requireduse="required" default="X"Include in required AND keep defaultDefault still informative

XSD fixed attribute enforces a constant value. MUST map to JSON Schema const keyword. XSD ConstructExampleJSON Schema FieldNotesAttribute with fixed<xs:attribute name="Version" type="xs:string" fixed="2.0"/>"const": "2.0"Value MUST match exactlyElement with fixed<xs:element name="ProfileType" type="xs:string" fixed="LIVE"/>"const": "LIVE"No other values allowedFixed + enumerationOne enumeration value matches fixedPrefer constConst is stricter and clearer

If a QName cannot be resolved in any loaded schema, the implementation MUST log an error and abort conversion of the parent type. ConditionDetectionActionImpactQName prefix missingPrefix not in namespace mapError: "Unknown namespace prefix"Stop current type expansionLocal name not foundNo matching type with local nameError: "Type not found"Abort parent typeAmbiguous resolutionMultiple matches across schemasError: "Ambiguous type reference"Abort conversion

Rarely used XSD constructs (e.g., xs:key, xs:notation) are not mapped. Their presence MUST trigger a controlled error. FeatureExampleActionNotesxs:keyIdentity constraintLog error; omit mappingNo JSON Schema equivalentxs:keyrefReference constraintLog error; omit mappingReferential integrity not supportedxs:assertXPath-based constraintLog error; abort typeDraft 7 lacks assertion support

Structural invalidity (malformed XML, contradictory constraints) MUST cause immediate termination. ConditionExampleActionOutputMalformed XMLUnclosed tagAbort processNo JSON producedConflicting occurrenceminOccurs=2, maxOccurs=1Error; abort elementParent type abortedInfinite recursion potentialDepth > 10 without cycleTreat as circularEmit circular marker

Implementations MUST meet all requirements below to claim conformance. Each requirement maps to a section defining its rules. #RequirementSectionVerification1Map all primitive types with correct JSON Schema type/format2.1-2.6Inspect generated primitives2Expand all complex types inline (no $ref)6.1Search for absence of "$ref"3Apply requiredness using minOccurs/use7.1Check required arrays4Represent choices via anyOf variants3.4Verify anyOf presence5Handle arrays with minItems/maxItems rules5.1-5.2Compare cardinality values6Include metadata fields title and x-onvif-type where applicable6.4Check object schemas for metadata7Detect circular references and mark appropriately6.3Find x-onvif-circular-ref flags8Map enumerations to enum arrays4.1Check enum presence9Map patterns and length facets correctly4.2Validate pattern/maxLength fields10Map numeric range facets to min/max fields4.4Validate minimum/maximum11Support union types with anyOf4.5Check anyOf usage12Represent nillable elements permitting null7.2Check anyOf null inclusion13Copy default values via default field7.3Inspect default fields14Enforce fixed values with const7.4Check const fields15Error on unsupported or invalid features8.2-8.3Review error log

This specification defines the mandatory and complete mapping rules for converting WSDL (Web Services Description Language) service definitions into Model Context Protocol (MCP) tool descriptors. Conformance: All implementations claiming conformance to this specification MUST follow these rules exactly. Any deviation will produce incompatible output. Version: 2.0 Date: November 13, 2025 Scope: WSDL service operations to MCP tool conversion Status: Prescriptive (all implementations MUST conform)

VersionDateChanges 2.02025-11-13Split from ONVIF_TO_MCP_CONVERSION_SPEC v1.3; focus on WSDL→MCP mapping only 1.32025-11-12Made specification prescriptive; removed all optional variations 1.02025-11-11Initial specification

This specification covers the conversion of WSDL service definitions to MCP tool descriptors, including: MCP tool structure and required fields Operation discovery from WSDL portType definitions Documentation extraction from WSDL annotations Input/output message mapping to JSON Schema Tool naming conventions Metadata preservation Dependency: Relies on the XSD_TO_JSON_SCHEMA_SPEC.md for converting XSD type definitions referenced by WSDL messages.

WSDL files define web service interfaces with: Types: XSD type definitions Messages: Input/output message definitions PortType: Abstract operations (converted to MCP tools) Binding: Protocol details (SOAP, HTTP) Service: Endpoint addresses

Each MCP tool is a JSON object describing a single callable operation with structured input and output schemas.

Each MCP tool MUST define all of the following fields: FieldTypeExampleNotesnamestringonvif.ptz.AbsoluteMoveUnique identifierservicestringPTZServiceService class namewsdlstring (path)wsdl/ver20/ptz/wsdl/ptz.wsdlRelative source pathoperationstringAbsoluteMoveWSDL operation namedescriptionstringOperation to move pan,tilt or zoom...Normalized, single-lineinput_schemaobject{"type":"object",...}Expanded request schemaoutput_schemaobject{"type":"object",...}Expanded response schemasourcestringfull-xsdFixed value

Detailed rules for each field: FieldRuleExtraction SourceValidationnameFormat: onvif.<service>.<operation>Service map + operationPattern matchserviceEnds with ServiceAuto-detectedSuffix checkwsdlRelative pathInput parameterNo leading slashoperationExact case preserved<wsdl:operation name="..."/>Case-sensitive comparedescriptionWhitespace normalized<wsdl:documentation>No newlines / tabsinput_schemaInline expansionWSDL input message elementNo $refoutput_schemaInline expansionWSDL output message elementNo $refsourceLiteral "full-xsd"FixedExact match

{ "name": "onvif.ptz.AbsoluteMove", "service": "PTZService", "wsdl": "wsdl/ver20/ptz/wsdl/ptz.wsdl", "operation": "AbsoluteMove", "description": "Operation to move pan,tilt or zoom to a absolute destination.", "input_schema": {"type":"object","properties":{}}, "output_schema": {"type":"object","properties":{}}, "source": "full-xsd" }

Operations are defined within <wsdl:portType> elements. <wsdl:portType name="PTZ"> <wsdl:operation name="AbsoluteMove">...

StepActionOutputNotes1Extract operation nameStringCase preserved2Extract documentationNormalized textFallback if absent3Resolve input messageMessage QNameFrom <wsdl:input>4Resolve output messageMessage QNameFrom <wsdl:output>5Convert messagesJSON SchemasInline expansion6Construct tool objectJSON objectAdd all fields

Documentation MUST be extracted from <wsdl:documentation> elements within <wsdl:operation>.

StepInputTransformationResult1Element nodeLocate childNode found2Raw textWhitespace normalizeSingle-line string3TextTrimClean description4ResultValidate non-emptyAccepted or fallback

Format: "ONVIF operation {OperationName}" used when documentation absent.

Messages reference XSD elements via <wsdl:part element="prefix:ElementName"/>.

Locate XSD element then expand its type inline.

StepActionResultNotes1Resolve messageWSDL message nodeInput or output2Extract element QNameQNameFrom part attribute3Find XSD elementElement nodeLookup in schemas4Expand typeJSON SchemaInline conversion5AttachAssign to tool fieldinput/output_schema

Empty complexType sequence maps to {"type":"object","properties":{}}.

All type references expanded inline, no $ref, circular detection per XSD spec Section 6.3.

Pattern: onvif.<service-name>.<operation>

Service TypeService NameExample ToolPTZ Serviceptzonvif.ptz.AbsoluteMoveDevice Managementdeviceonvif.device.GetDeviceInformationMedia Servicemediaonvif.media.GetProfilesImaging Serviceimagingonvif.imaging.GetImagingSettingsEvent Serviceeventonvif.event.SubscribeAnalytics Serviceanalyticsonvif.analytics.GetSupportedAnalytics

RuleConditionEnforcementExampleService lowercaseAlwaysConvert service component to lowercaseptzOperation case preservedAlwaysNo transformationAbsoluteMovePrefix constantAlwaysPrepend onvif.onvif.ptz.AbsoluteMoveUniquenessAcross all toolsAssert not already usedGlobal check

onvif.ptz.AbsoluteMove onvif.ptz.RelativeMove onvif.device.GetDeviceInformation onvif.media.GetProfiles onvif.imaging.GetImagingSettings

Implementations MAY include debugging metadata fields in JSON Schema objects (e.g. x-onvif-type, x-onvif-namespace).

Extract <xs:documentation> from referenced types as description when available.

Determine service via explicit config, WSDL analysis, or file path pattern.

File PatternService Class**/ptz.wsdlPTZService**/devicemgmt.wsdlDeviceService**/media.wsdlMediaService**/media2.wsdlMedia2Service

PrefixServicetptzPTZ ServicetdsDevice ServicetrtMedia Service (v1)tr2Media Service (v2)

No operations → log warning and return empty array.

Log error and skip operation if message undefined.

Log error and skip operation if element undefined.

Malformed WSDL → abort generation immediately.

An implementation conforming to this specification MUST satisfy all listed requirements. #RequirementSectionVerification1Generate all 8 required fields2.1Field count check2Name format compliance6.1Regex match3Documentation extraction or fallback4.1-4.3Non-empty description4Inline type expansion (no $ref)5.5Search absence of "$ref"5Empty responses mapped to empty object5.4Schema shape check6Relative WSDL path2.2No leading slash7Error handling rules applied9Log review