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

Re: Why CCTS?

  • To: xml-dev@l...
  • Subject: Re: Why CCTS?
  • From: <abcoatesecure-xmldev@y...>
  • 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@y...>
  • Reply-to: abcoatesecure-xmldev@y...

ccts xml
--- David Carver <d_a_carver@y...> 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.

PURCHASE STYLUS STUDIO ONLINE TODAY!

Purchasing Stylus Studio from our online shop is Easy, Secure and Value Priced!

Buy Stylus Studio Now

Download The World's Best XML IDE!

Accelerate XML development with our award-winning XML IDE - Download a free trial today!

Don't miss another message! Subscribe to this list today.
Email
First Name
Last Name
Company
Subscribe in XML format
RSS 2.0
Atom 0.3
 

Stylus Studio has published XML-DEV in RSS and ATOM formats, enabling users to easily subcribe to the list from their preferred news reader application.


Stylus Studio Sponsored Links are added links designed to provide related and additional information to the visitors of this website. they were not included by the author in the initial post. To view the content without the Sponsor Links please click here.

Site Map | Privacy Policy | Terms of Use | Trademarks
Free Stylus Studio XML Training:
W3C Member
Stylus Studio® and DataDirect XQuery ™are products from DataDirect Technologies, is a registered trademark of Progress Software Corporation, in the U.S. and other countries. © 2004-2013 All Rights Reserved.