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


Help: OASIS Mailing Lists Help | MarkMail Help

ebxml-core message

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

Subject: Re: more: Re: Tag Languages, UID's etc.


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

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]

Search: Match: Sort by:
Words: | Help

Powered by eList eXpress LLC