Attribute String Size Limit

[steve.thompson4]

Hope someone here can help.

Just had a file through a couple of errors, because the @key values were "invalid". Turns out, they were too long. What?!?

Anything over 72 characters causes the error. I'm hoping there's a setting we can 'set' to override this. That seems ridiculously short, when XML standards place no limit on an attribute's size. And I didn't find anything in searching the help(less) files. But maybe I just didn't use the right search terms.

I can certainly explain the 'why' we need the length we do for the values, but the point is, to assure uniqueness of 'key's in our instances, we need the length.

And these aren't the longest that I can see occurring.

Help?
Thanks!
Steve Thompson
TAD Technical
Boeing-IDS Technical Publications
+1(316)977-0515
MC K83-08
The truth is the truth even if nobody believes it, and a lie is a lie even if everyone believes it.

NOTICE: This communication may contain proprietary or other confidential information. If you are not the intended recipient, or believe that you have received this communication in error, please do not print, copy, retransmit, disseminate, or otherwise use the information. Also, please indicate to the sender that you have received this e-mail in error, and delete the copy you received. Any and all views expressed are the current understanding of the sender and should not be interpreted as an expression of official Boeing Company policy or position.

Les renseignements contenus dans ce message peuvent être confidentiels. Si vous n'êtes pas le destinataire visé ou une personne autorisée à lui remettre ce courriel, vous êtes par la présente avisé qu'il est strictement interdit d'utiliser, de copier ou de distribuer ce courriel, de dévoiler la teneur de ce message ou de prendre quelque mesure fondée sur l'information contenue. Vous êtes donc prié d'aviser immédiatement l'expéditeur de cette erreur et de détruire ce message sans garder de copie.

[steve.thompson4]

Oh, great, now I can't even spell...

That's "throw a couple of errors", not "through"... 😕

Steve Thompson
+1(316)977-0515
When the only tool you have is a hammer,
Everything looks like a hard disk...

[bibach]

Is this in an SGML DTD, XML DTD or XML Schema? And how is the "key"
attribute declared? What's the actual error message and when does it
occur?

-Brandon 🙂


On Fri, Nov 12, 2010 at 1:37 PM, EXT-Thompson, Steve
<steve.thompson2@boeing.com> wrote:
> Hope someone here can help.
>
> Just had a file through a couple of errors, because the @key values were "invalid". Turns out, they were too long. What?!?
>
> Anything over 72 characters causes the error. I'm hoping there's a setting we can 'set' to override this. That seems ridiculously short, when XML standards place no limit on an attribute's size. And I didn't find anything in searching the help(less) files. But maybe I just didn't use the right search terms.
>
> I can certainly explain the 'why' we need the length we do for the values, but the point is, to assure uniqueness of 'key's in our instances, we need the length.
>
> And these aren't the longest that I can see occurring.
>
> Help?
> Thanks!
> Steve Thompson
> TAD Technical
> Boeing-IDS Technical Publications
> +1(316)977-0515
> MC K83-08
> The truth is the truth even if nobody believes it, and a lie is a lie even if everyone believes it.
>
> NOTICE: This communication may contain proprietary or other confidential information. If you are not the intended recipient, or believe that you have received this communication in error, please do not print, copy, retransmit, disseminate, or otherwise use the information. Also, please indicate to the sender that you have received this e-mail in error, and delete the copy you received. Any and all views expressed are the current understanding of the sender and should not be interpreted as an expression of official Boeing Company policy or position.
>
> Les renseignements contenus dans ce message peuvent être confidentiels. Si vous n'êtes pas le destinataire visé ou une personne autorisée à lui remettre ce courriel, vous êtes par la présente avisé qu'il est strictement interdit d'utiliser, de copier ou de distribuer ce courriel, de dévoiler la teneur de ce message ou de prendre quelque mesure fondée sur l'information contenue. Vous êtes donc prié d'aviser immédiatement l'expéditeur de cette erreur et de détruire ce message sans garder de copie.
>
>
>
>
>

[largyres]

Have you looked at your outputrecordlength (or smthg) setting in Preferences?

-Lou Argyres

Continuing Education of the Bar - California
Oakland, CA
Lou.Argyres@ceb.ucla.edu


In Reply to Steve Thompson:

Oh, great, now I can't even spell...

That's "throw a couple of errors", not "through"... 😕

Steve Thompson
+1(316)977-0515
When the only tool you have is a hammer,
Everything looks like a hard disk...

[steve.thompson4]

Great call, Lou!

We changed the user's outputrecordlength to "Infinity", just to see, and voila' ! And the reason we hadn't seen it in non-key attributes in the same data that were even longer, is that those attributes contained commas (I believe that's why, anyway.).

So, easy fix. Whenever processing this particular book, reset to "Infinity". We may even look into automating the reset, so they don't have to mess with it.

Thank You, Everyone!
Steve Thompson
+1(316)977-0515
----------

[largyres]

Glad to helpSteve. Quick question if you don't mind:

Were the errors reported outside of Arbortext Editor? That's the only place I've ever seen problems with outputrecordlength, but your attributes with commas might warrant opening a call with PTC if an error came from inside Editor.

- Lou

Lou.Argyres@ceb.ucla.edu

[steve.thompson4]

The only place we had an error was in loading to the Editor window. The only real problem from that was the fact that it turned off context checking.

The attributes with commas did not have a problem. May not have been clear on that. The point of mentioning them was, they were longer, so could (should?) have already thrown the same error. Seems to me the reason they hadn't already caused a problem was the presence of the commas. Maybe not.

At this point (doing deliveries), insufficient time to test that theory.

Thanks, again,
Steve Thompson
+1(316)977-0515