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

 


Help: OASIS Mailing Lists Help | MarkMail Help

 


 

   Re: Why CCTS?

[ Lists Home | Date Index | Thread Index ]
  • To: xml-dev@lists.xml.org
  • Subject: Re: Why CCTS?
  • From: <abcoatesecure-xmldev@yahoo.co.uk>
  • Date: Tue, 17 Jan 2006 20:31:41 +0000 (GMT)
  • Domainkey-signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.co.uk; h=Message-ID:Received:Date:From:Reply-To:Subject:To:In-Reply-To:MIME-Version:Content-Type:Content-Transfer-Encoding; b=Mvr8p7onxF7sl3Cguo73FjY37mKwcOjCCuCvVWAdUQFTWmcFgbO111hBddH8Hnw3xpIRJr6OJfB+IW78Z9J0a1oP2QD25KNaJpYoNoXfU5qrFpksBh16s0Tqr8Ue+Y0CoW0LHB//hpQBAqnBKNzjGAe/frpFbiMW0bS8b8J/faM= ;
  • In-reply-to: <43CCF774.1030900@yahoo.com>
  • Reply-to: abcoatesecure-xmldev@yahoo.co.uk

--- David Carver <d_a_carver@yahoo.com> wrote:

> A follow up question, have you noticed anything in
> the way of performance issues in regards to
> implementing CCTS?

I should mention that CCTS per se is a data modelling
methodology.  It doesn't cover how to create XML
Schemas from your models.  The ATG2 group is working
on "naming and design rules" for that.

I'm not sure whether namespaces are such an issue. 
The XML Schemas that you get from a CCTS model won't
necessarily be the most compact XML representation. 
In the case of UBL, there are elements to contain
re-usable data type values, and these are wrapped in
an element that determines the specific context of
that data.  This means you can know the data types
without having to use Schema-aware processing, but it
potentially doubles the size of some XML documents (or
fragments thereof).  I would expect this to have more
impact than namespaces will.

That said, people can get too caught up in shaving
milliseconds off the time to parse a single document. 
I haven't had to work on any systems yet where the XML
parsing time was a significant factor in the full
end-to-end processing time for a business use case. 
I'm not saying that such situations don't exist, but I
think some people optimise first before asking whether
the optimisation will deliver a significant (i.e.
noticeable) return.

I hope at some stage we can get to a standard
compression method for such rich but verbose XML
messages, so that we can have our cake and eat it too.
 It worries me that some groups that do have large XML
volumes to process end up trying to do things like
using short meaningless element names, or attribute
content where element content would be more
appropriate, all just to try and save bandwidth. 
That's another thread, however.

Cheers, Tony.




 

News | XML in Industry | Calendar | XML Registry
Marketplace | Resources | MyXML.org | Sponsors | Privacy Statement

Copyright 2001 XML.org. This site is hosted by OASIS