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

 


Help: OASIS Mailing Lists Help | MarkMail Help

ubl-ndrsc message

[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]