[XML-DEV Mailing List Archive Home] [By Thread] [By Date] [Recent Entries] [Reply To This Message]

Re: The <any/> element: bane of security or savior of versioni

• From: "Stephen Green" <stephengreenubl@g...>
• To: "noah_mendelsohn@u..." <noah_mendelsohn@u...>
• Date: Fri, 19 Oct 2007 22:07:10 +0100

Noah,

Very good points indeed. Thanks.

I would think of it like attachments to emails or SOAP with attachments:
You might ask the same thing of forwarded, forwarded, responses with
attachments to responses of emails with attachments... ad infinitum.
Yes there are practical limits but fortunately those are matters for
the software which can follow very well established precedents. But I
take the point well that it is very important to follow the design through.
The UBL version 2.1 is going through planning stages now and this is
crunch time to find out whether the versioning mechanisms proposed
will be workable. There were constraints (mainly economic) which meant
it had to wait till 2.1 was needed before the exact details of minor versioning
could be fully worked out though - a weakness indeed - but it is no small
task to find a workable way forward even after years of designing UBL's
schema design rules. Since it takes so long (for a library document
standard set of schemas like UBL) to work it all out it makes sense to
try to establish the resulting design as a pattern to save others this work
who don't have the luxury of such time but have to produce something
like UBL. To me it really does seem to be questionable (though with
optimism) that a workable minor versioning design can actually be
established for UBL (which has lots of imports and multiple
namespaces - a design which sought to follow ideals and best practices
all along). Fingers crossed :-)

Steve

On 19/10/2007, noah_mendelsohn@u... <noah_mendelsohn@u...> wrote:
> Stephen Green writes:
>
> > Interestingly, in UBL the 'any' is inside an optional construct
> > so parties concerned it might pose some problems for software
> > weaknesses or security can just impose a subsetting profile
> > which eliminates its use from their transactions.
>
> I haven't looked at the UBL language lately, and don't remember the
> details, but during our discussions of XSD 1.1 I suggested a design goal
> which I think got some serious attention:  whatever constructs we provide
> for versioning should scale to the case where there are many revisions.
> Question:  if the content within that optional construct is later revised,
> does that second revision get wrapped in yet another such construct?  If
> there are 50 revisions, can you wind up with 49 nested "extension"
> elements, and the requirement to know how deep down each such extension
> goes?
>
> This is not a critique of UBL.  My impression is that it has been designed
> with great care and insight.  I have seen other more naive proposals for
> "extension" elements.  They tend to have the advantage that you know where
> the extension content is, and the disadvantages that a) they are somewhat
> clumsy in the instance (would you want to wrap your HTML <img> tags in
> <extension> elements? and b) as noted above, it's not always clear how to
> scale them to multiple revisions.  Overall, I tend to prefer various
> flavors of open content.
>
> Noah
>
> --------------------------------------
> Noah Mendelsohn
> IBM Corporation
> One Rogers Street
> Cambridge, MA 02142
> 1-617-693-4036
> --------------------------------------
>
>
>
>
>


-- 
Stephen Green

Partner
SystML, http://www.systml.co.uk
Tel: +44 (0) 117 9541606

http://www.biblegateway.com/passage/?search=matthew+22:37 .. and voice

• Follow-Ups:
  • Re: The <any/> element: bane of security or savior of versioning?
    • From: Thomas Lord <lord@e...>

• References:
  • Re: The <any/> element: bane of security or savior of versioning?
    • From: "Stephen Green" <stephengreenubl@g...>
  • Re: The <any/> element: bane of security or savior of versioning?
    • From: noah_mendelsohn@u...