XSD Import

[SarahPrice]

I am in the process of creating a new XSD Schema. I'm using the xsd:import option to import tags from other schemas we are currently using.

Namespace prefixes are: ipc, mm, wm

Everything is working great until i tried to insert a <mm:table> tag that is referenced in one of the imported schemas. It gives me the correct wrapper tag but when it hits the required <mm:tgroup> tag it gives me an internal error saying that that <ipc:tgroup> tag is out of context. It is reading the <ipc:tgroup> tag instead of the <mm:tgroup> tag. I have tried this using a different XML editor and it inserts the tags as expected.

Any help to this matter would be greatly appreciated.

sarah

[ebenton]

I don't know very much about schemas, so others on list may have a better answer. In other words, I might be wrong. In a DTD, if you reference out to various, slightly-different entities for the CALS table model and the entity names are all the same, the DTD uses the first entity in the DTD and ignores the subsequent ones of the same name.
Maybe something like this is happening in your case.

[SarahPrice]

Thank you for your response and yes I believe that is correct.

I have found some documentation showing the limitations/issues with the Xerces-C parser that Arbortext uses. If I take out the import option to the other schema then all works great.

Was hoping someone would have some type of work around.

[ptc-953343]

It isn't a simple calling of the file twice, something is also
assigning a different namespace to the elements as well. Does the
schema work properly in other tools? Can you make an instance and
validate it outside of Arbortext and then see what Arbortext says to
that. Something has got Arbortext trying to insert the right required
tag but with the wrong namespace, seems like the schema is not correct.

It would help to see the schema statements and the table definitions
in particular to try and trouble shoot the problem.

..dan

[SarahPrice]

Yes I am able to validate outside of Arbortext. Altova's XMLSpy has a built in parser and it works correctly with the correct namespace. The imported Schemas have been around for at least a year without any problems.

Here import/namespace portion of the new schema:

<xsd:schema xmlns="&lt;a" style="COLOR:" blue;=" text-decoration:=" underline&quot;=" target="_BLANK" href="http://anytown.mil/custom/doctypes/imm"">http://anytown.mil/custom/doctypes/imm" xmlns:ipc=" xmlns:mm="

[SarahPrice]

Correction to Namespace at bottom

<xsd:schema xmlns="&lt;a" style="COLOR:" blue;=" text-decoration:=" underline&quot;=" target="_BLANK" href="http://anytown.mil/custom/doctypes/imm"">http://anytown.mil/custom/doctypes/imm" xmlns:ipc=" xmlns:mm="

[ptc-953343]

What does the table and tgroup information look like, that is where
the namespace appears to cause problems.

Do you have a test instance and does it validate with an mm:table and

[SarahPrice]

Yes I can validate the mm:table and mm:tgroup tags just find out side of Arbortext. If I create an XML document outside of Arbortext with those tags in it and then open it in Arbortext it validates fine. It only appears to be a problem when I am inserting a mm:table tag inside an XML document in Arbortext.

I think you are right about the bug.

sarah

[ClayHelberg]

Hi Sarah--

To me, this sounds like it might be an issue with how your DCF is
configured. Arbortext has lots of under-the-hood machinery to manage
tables, and you may need to tweak your DCF to make it do what you want.

Have you set up your tables as custom table models in your DCF file? If
not, try doing that and see if it straightens out table handling for
you. (Note: if you're using Styler for styling, you'll need to configure
the custom table models in your Styler stylesheet too.) For guidance on
how to do that, consult the online help, or look at the comments in
$ARBORTEXT/doctypes/dcfdtd/dcfdtd.dtd.

--Clay

[ClayHelberg]

Are you referring to setup in Styler or setup in the DCF? If you mean
Styler, you might need to double-check your DCF setup, make sure you
have the hierarchy defined properly there. If the DCF isn't set up
right, Styler won't pick up the hierarchy correctly to let you make the
corresponding changes there.

--C

[SarahPrice]

Thanks for the info. Clay. I tried setting it up under the custom table model however it does not give me the option to define a mm:tgroup element so when I insert the mm:table tag it is telling me that the mm:row tag is out of context.

Sarah

[SarahPrice]

I'm referring to the .dcf file. I'm not using styler.

Here is what I have in the .dcf file. It only gives me the option for Table, Row and Cell elements.

<tablemodeldefinitions>
<customtablemodel name="mm:table">
<table element="mm:table"/">
<row element="mm:row">
<cell element="mm:entry"/">
</row>
</customtablemodel>
</tablemodeldefinitions>

I'm trying to match it up to the table structure in the imported xsd file, which has a tgroup element.

Sarah

[ClayHelberg]

Did you try setting up your namespaced tgroup element as the table
element? That might be what you need. In that case, the mm:tgroup would
be the table element and the mm:table element would be considered a
wrapper element for the table.

Hmm. I just played around with this for a few minutes and I'm having
trouble getting it to work too. I created a namespaced custom table and
added it to a copy of axdocbook. I am seeing the same behavior you are,
i.e. when I try to insert a custom table, the table editor tries to
insert the wrong tgroup element for the wrapper, creating a context
error.

It seems to work OK with non-namespaced custom tables.

At this point Dan is probably right, time to file this as a bug with PTC
and see if they can sort it out for you.

--Clay

[SarahPrice]

Thank you so much for trying. I will file the bug report and see what happens.

sarah

[ptc-953343]

Don't go directly to a bug report, file it as a support call and see if we have missed something. I don't know what the response time is supposed to be like on bugs, but it won't be anytime soon, so if there is a workaround or mistake in the setup, you are better off starting with support first. Let them confirm the problem and then link the support call in so there is added documentation. ..dan --------------------------------------------------------------------------- Danny Vint Specializing in Panoramic Images

[SarahPrice]

Will do. Thanks.

sarah