Loading ...
Sorry, an error occurred while loading the content.

Re: More problems with GPX 1.1 and multiple namespaces

Expand Messages
  • David S. Wissenbach
    ... uses strict ... We ... laptop ... make ... means ... about ... for us. ... What I proposed previously was the use of an alternate strict schema, which
    Message 1 of 24 , Feb 1, 2005
    • 0 Attachment
      --- In gpsxml@yahoogroups.com, "azbithead" <azbithead@g...> wrote:
      >
      > We at Garmin want to continue to import and export GPX files in our
      > applications. If you release a new version of GPX that
      uses "strict"
      > processing for wildcards it will be difficult to do so.
      >
      > Our applications currently do not require Internet accessibility.
      We
      > chose this because there are use cases (most notably automotive
      laptop
      > usage) where Internet accessibility can be difficult. When strict
      > processing is specified the XML processor requires that all schemas
      > used in an instance document be available. If any are not available
      > the document will fail to validate. The only way we can hope to
      make
      > all possibles schemas available is if they are accessed via the
      > Internet. We chose to build the schemas we care about into our
      > executables so that we know they will always be available. That
      means
      > that we cannot validate wildcards that use unknown schemas. However
      > that's OK because, by definition, we don't care about data using
      > unknown schemas. Lax processing of wildcards allows us to fully
      > validate all the parts of a GPX document that we know and care
      about
      > and ignore the rest. Strict processing will make that impossible
      for us.
      >
      > Thanks,
      > Steve

      What I proposed previously was the use of an alternate strict
      schema, which can be specified with the schema location. Garmin
      could always use the default, lax version of the schema, regardless
      of what the author specified.

      Remember that MapSource did operate correctly with the proposed
      alternate schema. So I DID keep you needs in mind with this proposal.

      We would always publish a lax version of the schema, and a strict
      version of the schema.

      Those of us who choose to use the gpx_overlay and gpx_style schemas
      should also be able to benefit from the interoperability
      improvements imposed by unambiguous validation, just as Garmin has
      chosen to protect itself from poorly-formed data in the base
      specification.

      Also remember that this data is in the extension namespaces and not
      in the main namespace in the first place in order to preserve
      compatibility for the long term as required by commercial
      enterprises such as yours. In return, you might make a concession
      that allows those of us pioneering the overlay schema to progress.

      I think that the need for gpx_overlay and gpx_style come about
      because they address a few problems that the SVG working group has
      not addressed -- that text is specified at device resolution, and
      that the user agent can choose the cartographic transform. So
      eventually Garmin might want to support gpx_style and gpx_overlay as
      well. Or at least give use the benefit of your experience and tell
      us why not.

      Regards,
      Dave
    • Dan Foster
      Hello, Tuesday, February 1, 2005, 8:59:57 AM, David wrote: D What I proposed previously was the use of an alternate strict D schema, which can be specified
      Message 2 of 24 , Feb 1, 2005
      • 0 Attachment
        Hello,

        Tuesday, February 1, 2005, 8:59:57 AM, David wrote:

        D> What I proposed previously was the use of an alternate strict
        D> schema, which can be specified with the schema location. Garmin
        D> could always use the default, lax version of the schema, regardless
        D> of what the author specified.

        D> Remember that MapSource did operate correctly with the proposed
        D> alternate schema. So I DID keep you needs in mind with this proposal.

        I think we can take this even further, and arrive at a solution that
        works for everyone. From what I've understood from the emails on this
        topic, there are some perceived uses for a lax schema, but nobody has
        actually mixed in a non-validating schema yet, or has concrete plans
        to do so.

        If we can solve Garmin's issue, I strongly believe we
        should require all future GPX files to reference a strict schema, and
        that the strict schema should be the only version posted online.
        Since the lax version is only needed by MapSource, and MapSource
        stores its schemas within the application, there's no need to have a
        second version of the schema online.

        I believe Garmin can solve their local-validation issue with a few
        lines of code. This is conjecture based on two observations:
        1. GPX 1.1 schema is included as a resource in MapSource.
        2. Dave W's instance document that referenced a different GPX 1.1
        schema (strict) was correctly opened in MapSource.
        That shows that MapSource can validate against a schema that isn't a
        word-for-word copy of the actual schema used in the instance doc.

        My solution:
        1. Garmin includes the identical strict GPX 1.2 schema in their app.
        2. MapSource loads this schema into a string object
        "GPX_output_schema"
        3. MapSource copies this string object to "GPX_input_schema"
        4. MapSource replaces "##strict" with "##lax" in GPX_input_schema
        only.
        5. When importing a file, MapSource validates against
        GPX_input_schema.
        6. When exporting a file, MapSource validates (does MapSource even do
        this?) against GPX_output_schema.

        If MapSource doesn't do any validation of the GPX data it creates,
        there's an even simpler solution:
        Steve takes the strict GPX 1.2 schema and replaces "##strict" with
        "##lax" before pasting it into MapSource. No program changes
        required. This is essentially what Dave W did with his MapSource test
        - and it worked! (Dave made and referenced a strict 1.1 schema by
        replacing ##lax with ##strict and posting it on his Web site.)

        By replacing strict with lax before validating, MapSource is telling
        the XML parser "I only care about validating against the GPX base
        schema that I use. Ignore the extension schemas that I don't care
        about." That matches perfectly with what Garmin is trying to
        accomplish.

        --
        Dan Foster
      • azbithead
        I guess I m a little confused about the need for strict processing. Do you want it so that content for these overlay and style schemas is always validated? Or
        Message 3 of 24 , Feb 1, 2005
        • 0 Attachment
          I guess I'm a little confused about the need for strict processing. Do
          you want it so that content for these overlay and style schemas is
          always validated? Or is it that you actually want *any* data in an
          extension to be always validated?

          As an aside, I did some experimenting on the behavior associated with
          lax processing. My experiments seem to indicate that validation does
          not occur only if the root element of a wildcard is not recognized to
          be defined by any available schema. If the root element does appear to
          be defined by an available schema then that whole element and its
          children will be validated. Given that, perhaps lax processing is not
          as bad you think it is.

          - Steve
        • Dan Foster
          Hello, Tuesday, February 1, 2005, 1:31:06 PM, Steve wrote: a I guess I m a little confused about the need for strict processing. Do a you want it so that
          Message 4 of 24 , Feb 1, 2005
          • 0 Attachment
            Hello,

            Tuesday, February 1, 2005, 1:31:06 PM, Steve wrote:

            a> I guess I'm a little confused about the need for strict processing. Do
            a> you want it so that content for these overlay and style schemas is
            a> always validated? Or is it that you actually want *any* data in an
            a> extension to be always validated?

            I want all data in all GPX files to validate. I don't see how
            anything less could be acceptable. What's the point of saying "most
            of the data in your GPX file must validate", or "your base GPX must
            validate, but you can put garbage in <extensions>"?

            And by "validate", I mean "pass the SAXCount test". I don't mean
            "pass the MapSource test". As I understand it, the MapSource test
            only tests against the schemas that MapSource understands, which
            currently are the GPX 1.0 and 1.1 base schemas. MapSource is the only
            program I know of that checks incoming GPX data for any kind of
            correctness. The rest of us just run any files that generate program
            errors through SAXCount to determine who is at fault.

            If you mean something else when you say "validate", please let us know
            so there's no confusion.

            a> As an aside, I did some experimenting on the behavior associated with
            a> lax processing. My experiments seem to indicate that validation does
            a> not occur only if the root element of a wildcard is not recognized to
            a> be defined by any available schema. If the root element does appear to
            a> be defined by an available schema then that whole element and its
            a> children will be validated. Given that, perhaps lax processing is not
            a> as bad you think it is.

            I'd argue that if ##lax allows even a single error, we should use
            ##strict instead. The upside is that it catches *all* errors. The
            downsides are that:
            1. MapSource needs a slight change.
            2. People can't mix non-validating schemas in using <extensions>

            I think I addressed #1 in my last email. I'm interested to hear if
            you agree. If you don't, perhaps you'd be willing to post a code
            snippet that shows how you validate the GPX on input?


            If #2 (mixing in non-validating schemas) is going to be needed in the
            future, there's an easy way to implement this: create another
            sub-schema "gpx_lax" that just defines its own non-validating
            extensions element (using ##lax). Something like:
            <wpt>
            <extensions>
            <gpx_lax:lax-stuff-goes-here>
            <svg>...</svg>
            </gpx_lax:lax-stuff-goes-here>
            </extensions>
            </wpt>


            --
            Dan Foster
          • Simon St.Laurent
            ... It opens up a lot of possibilities to say that, actually. So long as the data in the extensions is well-formed, there s no need to validate that data if
            Message 5 of 24 , Feb 1, 2005
            • 0 Attachment
              egroups@... (Dan Foster) writes:
              >I want all data in all GPX files to validate. I don't see how
              >anything less could be acceptable. What's the point of saying "most
              >of the data in your GPX file must validate", or "your base GPX must
              >validate, but you can put garbage in <extensions>"?

              It opens up a lot of possibilities to say that, actually. So long as
              the data in the extensions is well-formed, there's no need to validate
              that data if you don't understand (or care) what the extension is about.

              It makes for a much more flexible system without people stepping on each
              other's toes everytime someone wants to do something different.

              Simon St.Laurent
              http://simonstl.com/
            • David S. Wissenbach
              ... processing. Do ... with ... does ... to ... appear to ... not ... Thanks for setting me straight, and thanks for caring enough to run this experiment. I
              Message 6 of 24 , Feb 1, 2005
              • 0 Attachment
                --- In gpsxml@yahoogroups.com, "azbithead" <azbithead@g...> wrote:
                >
                > I guess I'm a little confused about the need for strict
                processing. Do
                > you want it so that content for these overlay and style schemas is
                > always validated? Or is it that you actually want *any* data in an
                > extension to be always validated?
                >
                > As an aside, I did some experimenting on the behavior associated
                with
                > lax processing. My experiments seem to indicate that validation
                does
                > not occur only if the root element of a wildcard is not recognized
                to
                > be defined by any available schema. If the root element does
                appear to
                > be defined by an available schema then that whole element and its
                > children will be validated. Given that, perhaps lax processing is
                not
                > as bad you think it is.
                >
                > - Steve

                Thanks for setting me straight, and thanks for caring enough to run
                this experiment.

                I was able to replicate your testing with the same results. The test
                files, which contain validation errors in both gpx_style and map3d
                namespaces, throw validation errors with either lax or strict
                processing but not when the schema locations for the extension
                namespaces are missing.

                I've posted the test files at

                http://www.gpstrailmaps.com/map3d/1/1/strict/

                Regards,
                Dave
              • azbithead
                ... When I say validate I am referring to the processing performed by an XML processor that conforms to the XML Schema recommendation when it parses an
                Message 7 of 24 , Feb 2, 2005
                • 0 Attachment
                  --- In gpsxml@yahoogroups.com, Dan Foster <egroups@t...> wrote:
                  > And by "validate", I mean "pass the SAXCount test". I don't mean
                  > "pass the MapSource test". As I understand it, the MapSource test
                  > only tests against the schemas that MapSource understands, which
                  > currently are the GPX 1.0 and 1.1 base schemas. MapSource is the only
                  > program I know of that checks incoming GPX data for any kind of
                  > correctness. The rest of us just run any files that generate program
                  > errors through SAXCount to determine who is at fault.
                  >
                  > If you mean something else when you say "validate", please let us know
                  > so there's no confusion.

                  When I say "validate" I am referring to the processing performed by an
                  XML processor that conforms to the XML Schema recommendation when it
                  parses an instance document and determines that its data satisfies the
                  constraints specified in its associated schema(s). Note that this is
                  not my definition of the term but rather the definition of the XML
                  Schema recommendation. Pehaps it would be good for the sake of our
                  discussions if we defined a term other than "validate" for "pass the
                  SaxCount test" since "validate" already has a meaning in the larger
                  XML Schema context.

                  Here's how MapSource processes GPX documents: MapSource has the Xerces
                  parser (the same one as SaxCount) compiled and linked in. When
                  MapSource opens a GPX document it immediately passes the document to
                  the Xerces parser to be parsed and validated (as defined above).
                  MapSource supplies the schemas that it knows about (currently GPX 1.0
                  and 1.1 as well as others) to the Xerces parser for this processing.
                  MapSource configures the Xerces parser to disregard any
                  "schemaLocation" attributes contained in the instance and instead use
                  only the schemas we've supplied. If any part of the document fails to
                  validate (according to the rules of the supplied schemas), MapSource
                  is notified by Xerces and the document is rejected. Otherwise, Xerces
                  gives MapSource a DOM node tree that represents the document's
                  contents. MapSource first looks at the the namespace of the root node
                  to determine what kind of data is contained in the tree. This lets us
                  know if the document is a GPX 1.0, GPX 1.1 or other type of document.
                  Then MapSource traverses the node tree, extracts the data and stores
                  it in MapSource's internal data format.

                  Note that the lax processing specified for extensions in GPX 1.1
                  allows the Xerces parser to suspend validation for data in extensions
                  that have no schema or a schema that MapSource has not supplied. The
                  document as a whole will then pass the validation processing done by
                  Xerces and MapSource can then extract the data for the parts that
                  conform to the schemas supplied. In no case can MapSource do anything
                  with extension data defined by schemas that it doesn't understand.
                  This situation allows producers of GPX instance documents to insert
                  their own extensions, distribute them to programs like MapSource which
                  will be able to safely ignore the extension and still retrieve the
                  base GPX data.

                  - Steve
                • David S. Wissenbach
                  ... run ... test ... I should have said http://www.gpstrailmaps.com/gpx/1/1/strict/ (This time I cut and pasted.) Dave
                  Message 8 of 24 , Feb 2, 2005
                  • 0 Attachment
                    >
                    > Thanks for setting me straight, and thanks for caring enough to
                    run
                    > this experiment.
                    >
                    > I was able to replicate your testing with the same results. The
                    test
                    > files, which contain validation errors in both gpx_style and map3d
                    > namespaces, throw validation errors with either lax or strict
                    > processing but not when the schema locations for the extension
                    > namespaces are missing.
                    >
                    > I've posted the test files at
                    >
                    > http://www.gpstrailmaps.com/map3d/1/1/strict/
                    >

                    I should have said

                    http://www.gpstrailmaps.com/gpx/1/1/strict/

                    (This time I cut and pasted.)

                    Dave
                  Your message has been successfully submitted and would be delivered to recipients shortly.