OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

unitsml message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]


Subject: NDR pt2 : GXS1


Here's some thoughts on the NDR rule GXS1, which describes the layout of the 
UnitsML schema itself. Peter already suggested to simply drop it, which I'm 
not opposed to. I just want to sum up my thoughts about it before we go ahead 
and take a decision on it.

so what does GXS1 dictate? Actually two things. First of all, a structure of 
the schema itself, which is not bad:

First the imports, followed by
the root element & type,
all elements,
all element types,
all attribute types,
and the copyright notice.

This doesn't hurt and IMO is a good structure for the XML schema. You at least 
know in which portion of the schema to look for something specific.

The second part of GXS1 dictates the order of all these things (elements, 
element types, attribute types): it's supposed to be alphabetized.

Again, this is not a bad thing, as it makes searching for specific things 
easier. This is not a bad thing, as long as we are talking about the *top 
level definitions*, that is the element declarations, their types and the 
attribute types that are direct children of the xsd:schema element, siblings 
to the root element and its type. Any ordering imposed on these elements / 
element types does not have any effect on how instance documents look.

A question arising in that respect is: Are the *child elements* and 
*attributes* of declared elements also supposed to be alphabetized? This is a 
very bad idea for UnitsML, cf. e.g. the children of the Dimension element. The 
order imposed here is that typical to SI documents related to units, not an 
alphabetic order. So _if_ that is the case, this part of the rule would be 
something we should not stick to, as the order of sub-elements in element 
declarations dictate the allowed order in instance documents.

Somewhat similar to attributes although not exactly for the same reason. By 
virtue of the XML standard the ordering of attributes is basically undefined 
to processors. So the order of attributes on element type definitions can be 
arbitrary -- any permutations of the attributes will be considered valid. So 
this time it's not instance documents that would be affected. What else? Well, 
the documentation. I would expect certain elements to come first in the 
documentation, so that you can immediately see that a given element is there, 
most prominently the xml:id ("can I directly address this element?") and 
xml:lang ("am I supposed to be multilingual here?") attributes.

But really, the deciding question is, does the alphabetic order extend to 
_inside_ the element type declarations? We somewhat assumed that during the 
last meeting, but reading the NDR GXS1 again, it seems we interpreted too much 
into it. If it's really only about the top-level declaration ordering, then 
it's not a bad thing to do. Furthermore, I have to say, we are currently not 
sticking to this rule. We could, without any effect on the documentation and 
instance documents, though, with minor effort. In that light, please 
reconsider: should we stick to GXS1, in the sense of ordering of top level 
declarations? Hmm. I think so.

Thanks for reading that far ;)

-Martin


[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]