Subject: [Ecrit] LoST schema omission

From: "Thomson, Martin" <[email-masked]>
Date: Mon, 7 Jan 2008 22:52:19 -0600

I just loaded the LoST schema to check out a few example messages.  Based on the compact schema, most of the example responses fail to validate.

The problem is that the "locationUsed" element (and all that is related to its use) is not defined in the schema.

Assuming some sort of consistency with the example:

  <lost:locationUsed id="6020688f1ce1896d"/>

...and assuming that you can provide a full location in this context (based on the client omitting the "id" attribute):

  <lost:locationUsed profile="civic">
    <ca:civicAddress><ca:country>AU</ca:country></ca:civicAddress>
  </lost:locationUsed>

The definitions for each message that includes location in the request need to be amended:

div {
  findServiceResponse =
    element findServiceResponse {
+      mapping+, locationValidation?, commonResponsePattern, locationUsed?
-      mapping+, locationValidation?, commonResponsePattern
    }
  listServicesResponse =
    element listServicesResponse { serviceList, commonResponsePattern }
  listServicesByLocationResponse =
    element listServicesByLocationResponse {
+      serviceList, commonResponsePattern, locationUsed?
-      serviceList, commonResponsePattern
    }
  getServiceBoundaryResponse =
    element getServiceBoundaryResponse {
      serviceBoundary, commonResponsePattern
    }
}

Then add the following:

  ## The location information used to generate the response 
  div {
    locationUsed = element locationUsed {
      attribute id { xsd:NCName } | locationInformation
    }
  }

Note that this allows for either the id, or an echo of the location information.

Also, to use the id properly, you need to replace both instances of "element location { locationInformation }" with "location" and define a "location" (cardinality of "+" and "*" still apply within the different contexts):

div {
  findService =
    element findService {
+      requestLocation,
-      element location { locationInformation }+,
      commonRequestPattern,
      attribute validateLocation {
        xsd:boolean >> a:defaultValue [ "false" ]
      }?,
      attribute serviceBoundary {
        ("reference" | "value") >> a:defaultValue [ "reference" ]
      }?,
      attribute recursive { xsd:boolean >> a:defaultValue [ "false" ] }?
    }
  listServices = element listServices { commonRequestPattern }
  listServicesByLocation =
    element listServicesByLocation {
+      requestLocation,
-      element location { locationInformation }*,
      commonRequestPattern,
      attribute recursive { xsd:boolean >> a:defaultValue [ "true" ] }?
    }
  getServiceBoundary =
    element getServiceBoundary { serviceBoundaryKey, extensionPoint }
}

Then add the definition as so:

  ## Location, used by findService and listServicesByLocation
  div {
    requestLocation = element location {
      attribute id { xsd:NCName }?, locationInformation
    }+
  }

(Note: It seems that you intended to have the cardinality of the location element in "listServicesByLocation" as 1..n, rather than 0..n.  The text in Section 11 states "one or more <location> elements".  I've assumed that here, if not, then add a trailing "?" to the line in "listServicesByLocation".)

I haven't used xsd:ID.  It might be more appropriate to use the ID type defined in "http://relaxng.org/ns/compatibility/datatypes/0.9", but that seems a little under-defined based on what I'm reading right now.

I also recommend changing the type of the service number to be based on xsd:token to allow for non-meaningful whitespace.  Based on the given pattern, whitespace is illegal (<serviceNumber> 911</serviceNumber> == bad, for more than one reason).  That is unintuitive, so a small change is appropriate:

      element serviceNumber {
        xsd:string { pattern = "[0-9*#]+" }
      }?,
->
      element serviceNumber {
        xsd:token { pattern = "[0-9*#]+" }
      }?,

The same goes for "message" and maybe "appUniqueString".  xsd:string should be used rarely, unless you particularly like whitespace nightmares (see [1]).

Cheers,
Martin 

[1] http://books.xmlschemata.org/relaxng/relax-CHP-7-SECT-6.html

------------------------------------------------------------------------------------------------
This message is for the designated recipient only and may
contain privileged, proprietary, or otherwise private information.  
If you have received it in error, please notify the sender
immediately and delete the original.  Any unauthorized use of
this email is prohibited.
------------------------------------------------------------------------------------------------
[mf2]
_______________________________________________
Ecrit mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/ecrit