[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
Subject: Re: more: Re: Tag Languages, UID's etc.
Martin, This latest draft does however appear to be the closest we've got yet to getting this right. Your points below are valid and I would suggest as public comments and refinements they are not inconsistent with the text as it stands (appart from the obvious typos that you point out - met instead of meta - etc). Item a) I like the use of the ::suffix to the UID to denote versioning. Does not have to be timestamp of course - V01, V02, etc work too. Omitting the version ::suffix would also imply 'latest version'. Item b) Your point on the complex type names is true - this has come to us from the W3C schema work - and their model scope is for a 'closed world' not a global registry enabled one as is ours. I think this is OK - since the registry path itself denotes an implied namespace. You only get into trouble if you have a compound document and the same complex type name is used in different context. At this point - since we introduced complextype name to accommodate the W3C work - we can probably just leave this as an open issue. Ultimately the solution is for the W3C to align their work with ours - but thats going to take more time and politics. Supporting the complextype is a good first step regardless of the scope issue. Item c) Moving on - the UID to Registry scope - my thought on this is that industry groups will assign UIDs and therefore that is why we do not need to limit this. A registry may of course contain multiple domains. Best practice guidelines will therefore take care of this. No system is foolproof if someone really wants to break it - our should be a best compromise to provide a lightweight implementation model. Item d) This is a 'bug' in the wording. There is certainly no such restriction within Registry. I think I'm agreeing with all of your points here - and also the existing TA wording. Just we need to clean up and clarify some of these boundary conditions so implementers know that they are either covered specifically, or covered by scope and use constraints. Thanks, DW. ================================================== Message text written by Martin Bryan > Personally I would not like to see this section (7.3) approved as it stands for a number of reasons: a) it does not allow versioning of objects, so that you cannot update models, find all different versions of a model, distinguish which version applied at which time (despite what the third of the bulleted items implies) b) it requires different registries to ensure that a particular complextype name has not been assigned in another registry (you cannot distinguish which registry assigned the complextype name) c) it requires different registries to agree what set of UIDs they assign asn the UID is not associated with a registry name d) It only allows names to be applied to Meta Models, not to the names of objects defined using these metamodels. I would prefer to see references to UIDs made in the following form: namespace:UID="UID::timestamp" or UID="http://www.myweb.org/registryID/UID::timestamp" In these examples the prinicple difference is that the namespace prefix, or the registry web address, act as qualifiers that allow users to distinguish between UIDs assigned in different places, while the timestamp allows them to distinguish between different versions of a model that are made a different times over the lifecycle of the metamodel. Martin Bryan <
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
Powered by eList eXpress LLC