-
Notifications
You must be signed in to change notification settings - Fork 22
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Rules for creating namespace URI and namespace prefix #235
Comments
For the United States in constructing its IWXXM documents, it makes use of the default namespace and changes its definition as appropriate. Thus, many of the elements often do not have a namespace prefix. This was done as part of an effort to reduce the size of the IWXXM documents. |
I would like to go a little deeper into situations where we need unique namespace prefix. Case IIn a COLLECT example with multiple versions of IWXXM METAR reports described in a previous post:
There is no need to have separate namespace prefixes for each IWXXM version Case IIIn the single schematron rule set which has to handle multiple versions of IWXXM mentioned in another post, different namespace prefixes will have to be used to identify different namespace URIs as they are being used at the same time.
In @mgoberfield 's case, the use of the default namespace prefix xs is fine until the IWXXM message is being included in some other XML document which is also using the default namespace prefix. In XML one can override an in-scope namespace declaration so this is technically okay, but it may look a bit less clean (I have to admit that this is a mysophobic view). If Case I above is the only situation we will encounter, then we probably only need to define one namespace prefix for IWXXM extension like iwxxmext to improve the representation. We may need a more complicated way to create namespace prefix in Case II, but the only use case I have is the schematron rule set I am making. I would be pleased if anybody could advise me other possible use cases under Case II. |
As there were no further discussions since Aug 2020, may I conclude with the following:
If there is no further views I will apply the above notations in #214. |
Will it be a recommendation for producers of IWXXM data? Or do you mean the Schematron file which is under our control? |
I will say this is only an indication on what we will be doing with the schema/schematron. It is not a recommendation for producers, although they are free to follow. |
This issue intends to continue and extend the discussion in #214 and the excellent write up on IWXXM extension @mgoberfield has created.
While XML namespace is supposed to be local to the XML document, there are increasing concern when elements from different XML documents are being consolidated, for example, into a new output from a SWIM service.
In Mark's document he has indicated a possible method to create a namespace URI. This URI is not necessarily resolvable, as xsi:schemaLocation should be used to indicate the location of the schema involved. Making this URI (e.g. http://icao.int/iwxxm/3.0./) return useful information with regard to this namespace is definitely a heartwarming feature.
Personally I don't see great issues on possible clashing of namespace URI, except that some users may forget to change it from some sample defaults like "http://foobar.com".
As with namespace prefix #214 has already mentioned some method, like
xmlns:iwxxm30="http://icao.int/iwxxm/3.0"
. @moryakovdv is suggesting iwxxm3_1_0 for IWXXM version 3.1.0.I would like to open up the floor for further suggestions, especially for namespace prefixes for IWXXM extensions.
The text was updated successfully, but these errors were encountered: