diff --git a/XsdToStruct.jl/dev/.documenter-siteinfo.json b/XsdToStruct.jl/dev/.documenter-siteinfo.json index 9180635..b10b9ff 100644 --- a/XsdToStruct.jl/dev/.documenter-siteinfo.json +++ b/XsdToStruct.jl/dev/.documenter-siteinfo.json @@ -1 +1 @@ -{"documenter":{"julia_version":"1.10.4","generation_timestamp":"2024-07-19T20:25:04","documenter_version":"1.5.0"}} \ No newline at end of file +{"documenter":{"julia_version":"1.10.4","generation_timestamp":"2024-07-19T20:30:00","documenter_version":"1.5.0"}} \ No newline at end of file diff --git a/XsdToStruct.jl/dev/docstrings/index.html b/XsdToStruct.jl/dev/docstrings/index.html index ff51179..203ec86 100644 --- a/XsdToStruct.jl/dev/docstrings/index.html +++ b/XsdToStruct.jl/dev/docstrings/index.html @@ -7,27 +7,27 @@ "remote_file" => "https://url.to.last/xsd/file" ) julia> xsd_modules_path = joinpath("output", "path", "for", "xsd", "modules") -julia> generate_modules(xsd_locations, xsd_modules_path)source
XsdToStruct.get_field_indices_of_type — Method
get_field_indices_of_type(
+julia> generate_modules(xsd_locations, xsd_modules_path)
source
XsdToStruct.get_field_indices_of_type — Method
get_field_indices_of_type(
     node::Union{ComplexTreeNode, SchemaTreeNode},
     ::Type{T}
-) where T <: AbstractFieldData

Find indices for all elements in the fields attribute of the given node which are of the given FieldData type. Note that this does not include the child fields in the case of a ComplexTreeNode.

source
XsdToStruct.parse_xsd_element_child — Method
parse_xsd_element_child(
+) where T <: AbstractFieldData

Find indices for all elements in the fields attribute of the given node which are of the given FieldData type. Note that this does not include the child fields in the case of a ComplexTreeNode.

source
XsdToStruct.parse_xsd_element_child — Method
parse_xsd_element_child(
     xsd_element::XMLElement,
     parent_name::AbstractString
-)::Tuple{FieldData, AbstractTreeNode}

Extract child node from xsd element with a type defined inside the element

source
XsdToStruct.qualified_type — Method
qualified_type(
+)::Tuple{FieldData, AbstractTreeNode}

Extract child node from xsd element with a type defined inside the element

source
XsdToStruct.qualified_type — Method
qualified_type(
     field_data::Union{FieldData, ChoiceFieldData},
     xsd_namespace::AbstractString
-)::String

Return the qualified type name for the given field_data relative to the namespace defined by the xsd. Hence if any leading xsd namespace part is present in the qualified type name it will be removed.

source
XsdToStruct.qualified_type — Method
qualified_type(
+)::String

Return the qualified type name for the given field_data relative to the namespace defined by the xsd. Hence if any leading xsd namespace part is present in the qualified type name it will be removed.

source
XsdToStruct.qualified_type — Method
qualified_type(
     field_data::Union{FieldData, ChoiceFieldData}
-)::String

Return the qualified type name for the given field_data as read from the xsd. This will include the xsd namespace explicitly if it was given in the xsd. If the qualified name relative to the xsd namespace is needed add the xsd namespace as a string as the second argument.

source
XsdToStruct.qualified_type — Method
qualified_type(field_data::GroupFieldData)::String

An Xsd group does not really have a qualified name, hence just the name is returned

source
XsdToStruct.required_julia_types — Method
required_julia_types(complex_node::ComplexTreeNode)::Vector{String}

Returns types which need to be defined in order for the struct definition of 'complex_node' to be valid.

source
XsdToStruct.xsd_to_struct_module — Method
xsd_to_struct_module(xsd_path::AbstractString, output_dir::AbstractString)::String

Generate Julia module corresponding to the given xsd file. The resulting Julia module will be placed in the given output_dir. The module generated will have the same name as the xsd namespace defined in the given xsd file. The path to the file with the generated code is given as a return value. The file generated will have the approximately the same name as the given xsd file but with a ".jl" extension instead of ".xsd". To use the generated module include the generated file that is returned by this function, and then use or import the module.

Examples

julia> using XsdToStruct
+)::String

Return the qualified type name for the given field_data as read from the xsd. This will include the xsd namespace explicitly if it was given in the xsd. If the qualified name relative to the xsd namespace is needed add the xsd namespace as a string as the second argument.

source
XsdToStruct.qualified_type — Method
qualified_type(field_data::GroupFieldData)::String

An Xsd group does not really have a qualified name, hence just the name is returned

source
XsdToStruct.required_julia_types — Method
required_julia_types(complex_node::ComplexTreeNode)::Vector{String}

Returns types which need to be defined in order for the struct definition of 'complex_node' to be valid.

source
XsdToStruct.xsd_to_struct_module — Method
xsd_to_struct_module(xsd_path::AbstractString, output_dir::AbstractString)::String

Generate Julia module corresponding to the given xsd file. The resulting Julia module will be placed in the given output_dir. The module generated will have the same name as the xsd namespace defined in the given xsd file. The path to the file with the generated code is given as a return value. The file generated will have the approximately the same name as the given xsd file but with a ".jl" extension instead of ".xsd". To use the generated module include the generated file that is returned by this function, and then use or import the module.

Examples

julia> using XsdToStruct
 julia> xsd_to_struct_module(joinpath("path", "to", "file.xsd"), joinpath("output", "dir"))
 julia> include(joinpath("output", "dir", "file", "file.jl"))
 julia> using file_xsd_namespace

or

julia> using XsdToStruct
 julia> xsd_to_struct_module(joinpath("path", "to", "file.xsd"), joinpath("output", "dir"))
 julia> include(joinpath("output", "dir", "file", "file.jl"))
-julia> import file_xsd_namespace
source
XsdToStruct.xsd_to_struct_module — Method
xsd_to_struct_module(xsd_path::AbstractString)::String

Generate Julia module corresponding to the given xsd file. The resulting Julia module will be placed in the same directory as the given xsd file. The path to the file with the generated code is given as a return value.

Examples

julia> using XsdToStruct
+julia> import file_xsd_namespace
source
XsdToStruct.xsd_to_struct_module — Method
xsd_to_struct_module(xsd_path::AbstractString)::String

Generate Julia module corresponding to the given xsd file. The resulting Julia module will be placed in the same directory as the given xsd file. The path to the file with the generated code is given as a return value.

Examples

julia> using XsdToStruct
 julia> xsd_to_struct_module(joinpath("path", "to", "file.xsd"))
 julia> include(joinpath("path", "to", "file", "file.jl"))
 julia> using file_xsd_namespace

or

julia> using XsdToStruct
 julia> xsd_to_struct_module(joinpath("path", "to", "file.xsd"))
 julia> include(joinpath("path", "to", "file", "file.jl"))
-julia> import file_xsd_namespace
source
+julia> import file_xsd_namespacesource diff --git a/XsdToStruct.jl/dev/index.html b/XsdToStruct.jl/dev/index.html index 6b5b7cd..bdd253e 100644 --- a/XsdToStruct.jl/dev/index.html +++ b/XsdToStruct.jl/dev/index.html @@ -31,4 +31,4 @@ "remote_file" => "https://url.to.some/xsd/file" ) xsd_modules_path = joinpath("some", "output", "path") -generate_modules(xsd_locations, xsd_modules_path)

In this case it will download the file from the given URL and save the output under the name given by the key in the dict, in this case "remote_file".

Using the generated structure definitions

If you want to use the generated structure definitions you only have to include the file in the newly created folder with the same name as the original XSD file except with a ".jl" extension. So for our "documentationexample.xsd" this will be "documentationexample.jl". The generated module will always depend on "AbstractXsdTypes" and "Reexport" so these packages need to be available where you want to use the structure definitions. Optionally "Dates" and "TimeZones" are also needed. The docstring of the generated module will list all the needed dependencies for that generated module.

The main module that is generated will have the same name as the target namespace of the given XSD file. This module will also export the generated types. Hence be careful when using these modules since they can inject many types that you might not expect into your code.

What is generated

Apart from the main file with the main module there will also be one or more extra files in the generated folder, these can be ignored. These extra files are already included in the main module which reexports the needed definitions from the other files. You might notice some extra namespaces when querying types from the main module but these can be ignored since everything that is needed is present in the namespace of the main module.

The main module will also contain a submodule called __meta that contains some extra information that could be useful. Most importantly, it contains the type of the root element which is needed when handling XML files.

Apart form the main file these is also a second file which contains a submodule with the structure definitions which has the "_struct" suffix. Apart from the structure definitions there are also a few utility functions that are defined in here. Mainly these will be related to input validation and default values for the schema types. For more information on these see the AbstractXsdTypes documentation.

Note on Dependencies

Each generated module depends a few extra packages, you will have to add those yourself to your environment. All modules depend upon:

And some also depend on:

The docstring of the generated module will always say which extra packages are needed.

Known limitations

The XSD specification is quite extensive and complex hence not everything is completely supported. Here is a non-exhaustive list of unsupported XSD features:

+generate_modules(xsd_locations, xsd_modules_path)

In this case it will download the file from the given URL and save the output under the name given by the key in the dict, in this case "remote_file".

Using the generated structure definitions

If you want to use the generated structure definitions you only have to include the file in the newly created folder with the same name as the original XSD file except with a ".jl" extension. So for our "documentationexample.xsd" this will be "documentationexample.jl". The generated module will always depend on "AbstractXsdTypes" and "Reexport" so these packages need to be available where you want to use the structure definitions. Optionally "Dates" and "TimeZones" are also needed. The docstring of the generated module will list all the needed dependencies for that generated module.

The main module that is generated will have the same name as the target namespace of the given XSD file. This module will also export the generated types. Hence be careful when using these modules since they can inject many types that you might not expect into your code.

What is generated

Apart from the main file with the main module there will also be one or more extra files in the generated folder, these can be ignored. These extra files are already included in the main module which reexports the needed definitions from the other files. You might notice some extra namespaces when querying types from the main module but these can be ignored since everything that is needed is present in the namespace of the main module.

The main module will also contain a submodule called __meta that contains some extra information that could be useful. Most importantly, it contains the type of the root element which is needed when handling XML files.

Apart form the main file these is also a second file which contains a submodule with the structure definitions which has the "_struct" suffix. Apart from the structure definitions there are also a few utility functions that are defined in here. Mainly these will be related to input validation and default values for the schema types. For more information on these see the AbstractXsdTypes documentation.

Note on Dependencies

Each generated module depends a few extra packages, you will have to add those yourself to your environment. All modules depend upon:

And some also depend on:

The docstring of the generated module will always say which extra packages are needed.

Known limitations

The XSD specification is quite extensive and complex hence not everything is completely supported. Here is a non-exhaustive list of unsupported XSD features: