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

 


Help: OASIS Mailing Lists Help | MarkMail Help

ubl-dev message

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


Subject: SV: [ubl-dev] Réf. : Re: [ubl-dev] RE: UML meta-modeling of UN/CEFACT Core Components



>  It would be tempting to
>write the contexts as such:

><Contexts>
>    <GeopoliticalContext>
>            <Value> Canada</Value>
>    </GeopoliticalContext>
>    <SomeOtherContext>
>             <Value>1234</Value>
>    </SomeOtherContext>
>...

okay

>But this creates problems for managibility over time.  We cannot be so
>arrogant and to think we have thought of everything today. People will
>need to extend and add to our work over time.  

>A better way to write it is to 'think" about future developers/users and
>write XML in a format so other tokens can be added without breaking
>forwards or backwards compatibility.

><Contexts>
>    <Context  name="Geopolitical" qualifier="ISO-3166" value="CA-on" />
>    <Context name="myAddedContext" qualifier="whatever"
>value="itsNotImportantToOthers" />
>...

The breaking of forwards and backwards compatibility is managed by a
model(by model I mean conceptual model, and not UML model) for how forwards
and backwards compatibility works. Basically the second version of markup
is, I would guess, forced on you by a model that limits extensibility, if
you are using XSD for validation, then you will want to have the contexts
with multiple context child nodes. 

Extensibility in the wild is often done via the use of namespaces, thus what
one wants is a namespace handling model that follows the model which
developers are most used to, which is non-essential namespaces to
application x are ignored by application x, this allows developers to extend
a type of xml dialect with new semantics relevant to them without worrying
about breakage, unfortunately this is not the model that XSD is especially
good at handling. 

finally when you talk about forwards or backwards compatibility I think that
what one should be discussing is a versioning strategy, how should version
1.0 processors relate to version 1.1 instances that are bound to our
namespace, in that case the general reaction is to say that in a version 1.0
instance read by a version 1.0 processor all markup in the target namespace
must conform to version 1.0 markup, in a version 1.1 instance all markup in
the namespace not conforming must be ignored, and it's subtree ignored,
sometimes one extends the dialect by using a construct mustUnderstand, so if
your first example was:

<mydoc version="1.1" xmlns="http://mydoc.org";>
<Contexts mustUnderstand="True">
    <GeopoliticalContext>
            <Value> Canada</Value>
    </GeopoliticalContext>
    <SomeOtherContext>
             <Value>1234</Value>
   </SomeOtherContext>
	<NewVersionContext><Value>282738</Value></NewVersionContext>
</Contexts>
</mydoc>

this should cause a mydoc 1.0 processor to fail because it mustUnderstand
everything under Contexts, and NewVersionContext is an element introduced
with version 1.1 

The question is not if one version is more or less extensible than the
other, they are both extensible, the question would be which makes for a
better understood model for developers, users etc. I have my preferences, I
think that the Contexts with multiple child context nodes is probably
preferable in comparison to the other example, but that a well-defined
versioning strategy and namespace handling model in the initial
specification is how one handles extensibility and forward backward
compatibility. 

Just my 0.02 kr. (I'm sorta getting screwed on the exchange rate here)


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