> Note that that means that you would almost certainly have to specify > collapse & that no values could ever start or end with a space or > contain more than one contiguous space.
This is what is specified in the openehr schema for most of the elements you are talking about. For instance, all types derived from OBJECT_ID have a value element with type xs:token - this has the whitespace facet set to collapse and is why I presume XMLSpy is feeling free to pretty print using extra spaces and tabs. In the case of where the type is xs:string, I'm guessing XMLSpy wouldn't add extra leading or trailing spaces (as that would be clearly changing the meaning of any element with whitespace set to preserve). I don't use oxygen or xmlspy so I can't really test this out. Rather than the question of whether to use attributes or elements, my question is - do we have xs:token or xs:string set correctly as the type in the schema for all elements - I'm not sure anyone has really gone through and systematically determined what the whitespace ramifications are for each element (should LOCATABLE_REF/path be a string or a token for instance? - without having the formal spec here with me I would think that a path would normally ignore leading and trailing spaces so perhaps it should be a token) Andrew
