[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: [ubl-ndrsc] Containership issue with current LCSC samples
Ooops. Forgot to copy the list... -----Original Message----- From: A Gregory [mailto:agregory@aeon-llc.com] Sent: Monday, March 03, 2003 12:38 AM To: Burcham, Bill Subject: RE: [ubl-ndrsc] Containership issue with current LCSC samples Bill: It's not discomfort (it's acute pain), and it's just about *any* piece of XSLT you could write regarding any of these documents. Here's the thing: An XPath expression used in an XSLT "select" the processor has to determine, by iterating over the nodes of the DOM, which nodes match and which don't. The way an XSLT processor works (in my understanding) is as follows... Look at the JoineryOrderResponse document. To grab a line item node, I need to write an expression that looks like this: <xsl:for-each select="/OrderResponse/cat:ReferencedOrderLine"> ... </xsl:for-each> Think about the evaluation that the processor has to do. It gets the root, and it gets the document-level element, OK. It then has to taste each and every node in the DOM to determine that the first several are *not* ReferencedOrderLine nodes. (Be aware that most XSLT transforms are not done with any reference to the schema after validation - the processor doesn't look into the schema to see what's where,. from what I understand) If, instead, we had a header and body container, then we could write this: <xsl:for-each select="/OrderResponse/cat:OrderLines/cat:ReferencedOrderLine"> ... </xsl:for-each> The processor would get the root, then get the document-level element, and then have to tase exactly *one* node in the DOM before moving on to the place where it wants to be. Within OrderLines, there would *only* be ReferencedOrderLine elements. This means I have saved my processor the work of tasting 6 wrong elements before getting to the one it wants. This is not an extreme case. The real problem comes into play when you are after a header element in a business document with 400 order lines. I have to check each and every immediate child node of the document-level node in order to determine that they are not a match for my select criteria. If I want to grab the cat:ID element, I have to taste 7 header fields (producing one match) and then 400 ReferencedOrderLine elements to produice 0 matches. This is true for every bit of data I want to select from the header information. This adds up, since I will query at least half a dozen times. If I just have containers, I remove this problem almost entirely - I have a handful of header stuff to iterate over (in this example, 6 different elements) and a stack of orders, which I will need to process anyway. What I don't want to do for each of my 400 line items is to have to tase an additional 6 child nodes when I could get away with only doing it for one before i got my match. I hope this helps explain my problem. What I don't know is whether some clever individual has come up with away to avoid this problem. It is not the main thing that makes XSLT bad for production environments - that problem is the use of memory to build DOM trees - but it seems like it might be significant. I don't understand why our XML shouldn't be optimized for XSLT, especially when IMHO (the "H" is for "humble", by the way) adding a few containers will make the XML easier to understand, anyway (remember Jon's comment from the people at RosettaNet that users wanted containers to make it easier to understand this stuff?) It wouldn't surprise me to discover that *all* DOM processing has to go through a similar type of calculation, and not just XSLT. Anyway, there it is. Cheers, Arofan -----Original Message----- From: Burcham, Bill [mailto:Bill_Burcham@stercomm.com] Sent: Friday, February 28, 2003 12:10 PM To: 'A Gregory'; UBL NDR Subject: RE: [ubl-ndrsc] Containership issue with current LCSC samples Arofan: can you be more specific? May I see the offending XSLT code? Are you processing OfficeSupplyOrderInstance.xml from the 0p70 supplementary materials? I don't mean to sound harsh, but if we are going to debate, then we need new information -- not just a reiteration of your discomfort. -----Original Message----- From: A Gregory [mailto:agregory@aeon-llc.com] Sent: Friday, February 28, 2003 5:40 AM To: UBL NDR Subject: [ubl-ndrsc] Containership issue with current LCSC samples Folks: I really hate to raise the whip over this particular part of the donkey again (my arm is tired from flogging) but I'm going to anyway... <<munch>> ---------------------------------------------------------------- To subscribe or unsubscribe from this elist use the subscription manager: <http://lists.oasis-open.org/ob/adm.pl> ---------------------------------------------------------------- To subscribe or unsubscribe from this elist use the subscription manager: <http://lists.oasis-open.org/ob/adm.pl>
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]