Felix
  1. Felix
  2. FELIX-3471

Support Schema validation for MetaData XML documents

    Details

    • Type: Bug Bug
    • Status: Open
    • Priority: Major Major
    • Resolution: Unresolved
    • Affects Version/s: metatype-1.0.4
    • Fix Version/s: None
    • Component/s: Metatype Service
    • Labels:
      None

      Description

      MetaData XML documents are not being W3C Schema-validated.

      Provide option for doing so.

      Thanks
      Alex

        Activity

        Hide
        Felix Meschberger added a comment -

        That would be quite heavy to do relying on at least one 3rd party library.

        What would be the benefit ?

        Show
        Felix Meschberger added a comment - That would be quite heavy to do relying on at least one 3rd party library. What would be the benefit ?
        Hide
        Alexandre Castro Alves added a comment -

        The lifecycle I intended would be to validate only during a bundle install (e.g. application deploy), so don't think the cost would be prohibitive. The benefit is that design-time errors would be caught during deployment, rather than later at runtime when the bundle (e.g. application) started processing.

        Show
        Alexandre Castro Alves added a comment - The lifecycle I intended would be to validate only during a bundle install (e.g. application deploy), so don't think the cost would be prohibitive. The benefit is that design-time errors would be caught during deployment, rather than later at runtime when the bundle (e.g. application) started processing.
        Hide
        Felix Meschberger added a comment -

        Actually the metadata is not read when the bundle is loaded but when the data is actually accessed, which may in-fact never be the
        case or very late in the lifecycle of the bundle.

        I fear this puts quite a heavy load on the system just to catch issues, which might also be caught at build time.

        If it is for "design-time" errors, these should IMHO be caught during building .. just like Java errors are caught during compilation.

        Finally, the schema is relatively lax in that it allows for any attributes and any elements to be added anywhere in addition to the defined ones. The defined ones are validated once the files are loaded.

        Show
        Felix Meschberger added a comment - Actually the metadata is not read when the bundle is loaded but when the data is actually accessed, which may in-fact never be the case or very late in the lifecycle of the bundle. I fear this puts quite a heavy load on the system just to catch issues, which might also be caught at build time. If it is for "design-time" errors, these should IMHO be caught during building .. just like Java errors are caught during compilation. Finally, the schema is relatively lax in that it allows for any attributes and any elements to be added anywhere in addition to the defined ones. The defined ones are validated once the files are loaded.
        Hide
        Alexandre Castro Alves added a comment -

        My application is a design-time application and is invoking the 'load metadata' during a bundle install.

        If the schema is lax, then there won't be too much of a performance hit, further this feature should be made optional, so client can determine if the hit is accessible in the client's context.

        As it happens, I did run into a situation where the customer provided an invalid XML document that could have been caught sooner should the metatype implementation have validated it. Of course, I could validate it in the application itself, however we would be parsing the document twice, once for validation, and once by the metatype implementation, which doesn't seem ideal.

        Thanks
        Alex

        Show
        Alexandre Castro Alves added a comment - My application is a design-time application and is invoking the 'load metadata' during a bundle install. If the schema is lax, then there won't be too much of a performance hit, further this feature should be made optional, so client can determine if the hit is accessible in the client's context. As it happens, I did run into a situation where the customer provided an invalid XML document that could have been caught sooner should the metatype implementation have validated it. Of course, I could validate it in the application itself, however we would be parsing the document twice, once for validation, and once by the metatype implementation, which doesn't seem ideal. Thanks Alex
        Hide
        Felix Meschberger added a comment -

        Just stumbled upon this note in section 105.7.1 on the XML Schema:

        "This section describes the schema of the meta type resource. This schema is not intended to be used during runtime for validating meta type resources. The schema is intended to be used by tools and external management systems."

        I think reading the metadata should allow for enough validation of the input data.

        If you have invalid XML for which you think error reporting is insufficient, I would be happy to add better error reporting while reading the file.

        Show
        Felix Meschberger added a comment - Just stumbled upon this note in section 105.7.1 on the XML Schema: "This section describes the schema of the meta type resource. This schema is not intended to be used during runtime for validating meta type resources. The schema is intended to be used by tools and external management systems." I think reading the metadata should allow for enough validation of the input data. If you have invalid XML for which you think error reporting is insufficient, I would be happy to add better error reporting while reading the file.
        Hide
        Matt Bishop added a comment -

        I think there is a bug in all the metatype XSDs, and particular in the metatype XSDs for v1.1.0 and 1.2.0. I am not sure where to file this bug, but I'll try here and see if it leads somewhere else.

        Simply put, one cannot create validatable MetaData documents that validate using these XSDs. The problem is that the namespace defined in the schema is not applied to the child elements correctly. Their <xsd:schema> header elements are missing the all-important elementFormDefault="qualified" attributeFormDefault="unqualified" pair to allow elements below the MetaData to be "found" by the parser.

        This leads from bad, but validatable (1.0.0, notice how only the MetaData element gets a prefix? prefixing the OCD and other children fails):

        <?xml version="1.0" encoding="UTF-8"?>
        <metadata:MetaData
        xmlns:metadata="http://www.osgi.org/xmlns/metatype/v1.0.0"
        xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
        xsi:schemaLocation="http://www.osgi.org/xmlns/metatype/v1.0.0 http://www.osgi.org/xmlns/metatype/v1.0.0/metatype.xsd">

        <OCD description="Configured Example Application" name="ConfigApp" id="ConfigApp">
        <AD name="Title" id="title" required="true" type="String" default="Default Title" description="Title for the Application"/>
        </OCD>

        <Designate pid="ConfigApp">
        <Object ocdref="ConfigApp"/>
        </Designate>
        </metadata:MetaData>

        To unvalidatable at all in 1.1.0 / 1.2.0:
        <?xml version="1.0" encoding="UTF-8"?>
        <metadata:MetaData
        xmlns:metadata="http://www.osgi.org/xmlns/metatype/v1.2.0"
        xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
        xsi:schemaLocation="http://www.osgi.org/xmlns/metatype/v1.2.0 http://www.osgi.org/xmlns/metatype/v1.2.0/metatype.xsd">

        <OCD description="Configured Example Application" name="ConfigApp" id="ConfigApp">
        <AD name="Title" id="title" required="true" type="String" default="Default Title" description="Title for the Application"/>
        </OCD>

        <Designate pid="ConfigApp">
        <Object ocdref="ConfigApp"/>
        </Designate>
        </metadata:MetaData>

        Also fails if you remove the metadata: prefix.

        <?xml version="1.0" encoding="UTF-8"?>
        <metadata:MetaData
        xmlns:metadata="http://www.osgi.org/xmlns/metatype/v1.2.0"
        xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
        xsi:schemaLocation="http://www.osgi.org/xmlns/metatype/v1.2.0 http://www.osgi.org/xmlns/metatype/v1.2.0/metatype.xsd">

        <metadata:OCD description="Configured Example Application" name="ConfigApp" id="ConfigApp">
        <metadata:AD name="Title" id="title" required="true" type="String" default="Default Title" description="Title for the Application"/>
        </metadata:OCD>

        <metadata:Designate pid="ConfigApp">
        <metadata:Object ocdref="ConfigApp"/>
        </metadata:Designate>
        </metadata:MetaData>

        Validation error:
        cvc-complex-type.2.4.a: Invalid content was found starting with element 'metadata:OCD'. One of '

        {OCD, Designate, WC[##other:"http://www.osgi.org/xmlns/metatype/v1.2.0"]}

        ' is expected.

        Taking out the prefix also fails. In short there is no clear way to use the 1.1.0 and 1.2.0 XSDs for their stated purpose of tools-driven document validation.

        Show
        Matt Bishop added a comment - I think there is a bug in all the metatype XSDs, and particular in the metatype XSDs for v1.1.0 and 1.2.0. I am not sure where to file this bug, but I'll try here and see if it leads somewhere else. Simply put, one cannot create validatable MetaData documents that validate using these XSDs. The problem is that the namespace defined in the schema is not applied to the child elements correctly. Their <xsd:schema> header elements are missing the all-important elementFormDefault="qualified" attributeFormDefault="unqualified" pair to allow elements below the MetaData to be "found" by the parser. This leads from bad, but validatable (1.0.0, notice how only the MetaData element gets a prefix? prefixing the OCD and other children fails): <?xml version="1.0" encoding="UTF-8"?> <metadata:MetaData xmlns:metadata="http://www.osgi.org/xmlns/metatype/v1.0.0" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:schemaLocation="http://www.osgi.org/xmlns/metatype/v1.0.0 http://www.osgi.org/xmlns/metatype/v1.0.0/metatype.xsd "> <OCD description="Configured Example Application" name="ConfigApp" id="ConfigApp"> <AD name="Title" id="title" required="true" type="String" default="Default Title" description="Title for the Application"/> </OCD> <Designate pid="ConfigApp"> <Object ocdref="ConfigApp"/> </Designate> </metadata:MetaData> To unvalidatable at all in 1.1.0 / 1.2.0: <?xml version="1.0" encoding="UTF-8"?> <metadata:MetaData xmlns:metadata="http://www.osgi.org/xmlns/metatype/v1.2.0" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:schemaLocation="http://www.osgi.org/xmlns/metatype/v1.2.0 http://www.osgi.org/xmlns/metatype/v1.2.0/metatype.xsd "> <OCD description="Configured Example Application" name="ConfigApp" id="ConfigApp"> <AD name="Title" id="title" required="true" type="String" default="Default Title" description="Title for the Application"/> </OCD> <Designate pid="ConfigApp"> <Object ocdref="ConfigApp"/> </Designate> </metadata:MetaData> Also fails if you remove the metadata: prefix. <?xml version="1.0" encoding="UTF-8"?> <metadata:MetaData xmlns:metadata="http://www.osgi.org/xmlns/metatype/v1.2.0" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:schemaLocation="http://www.osgi.org/xmlns/metatype/v1.2.0 http://www.osgi.org/xmlns/metatype/v1.2.0/metatype.xsd "> <metadata:OCD description="Configured Example Application" name="ConfigApp" id="ConfigApp"> <metadata:AD name="Title" id="title" required="true" type="String" default="Default Title" description="Title for the Application"/> </metadata:OCD> <metadata:Designate pid="ConfigApp"> <metadata:Object ocdref="ConfigApp"/> </metadata:Designate> </metadata:MetaData> Validation error: cvc-complex-type.2.4.a: Invalid content was found starting with element 'metadata:OCD'. One of ' {OCD, Designate, WC[##other:"http://www.osgi.org/xmlns/metatype/v1.2.0"]} ' is expected. Taking out the prefix also fails. In short there is no clear way to use the 1.1.0 and 1.2.0 XSDs for their stated purpose of tools-driven document validation.

          People

          • Assignee:
            Unassigned
            Reporter:
            Alexandre Castro Alves
          • Votes:
            0 Vote for this issue
            Watchers:
            3 Start watching this issue

            Dates

            • Created:
              Updated:

              Development