DTD to schema question

[LynnHales]

Folks, I've been doing a fair amount of research on this and it seems I have one problem that may keep me in the DTD world a bit longer.

Our DTD has several large referenced files containing general ENTITY replacement text (if anyone has ever parsed the 40051 DTD with 'dtgen' they have encountered those files. You normally will get several 'litlen' errors.) This replacement text contains markup, references to other editable ENTITIES and the text is generic required stuff the authors really don't need to redo for every TM.

My question is this (and I think I already know the answer BUT thought I'd toss it out for verification), can I call those files from a schema? My searches to date have said NO. 😞

If I cannot call those files, then converting to a schema won't work.

Many thanks.


Lynn

[ptc-953343]

Are these entities for the construction of the DTD or for use when
authoring? Sounds like these are for authoring purposes. If so, then it
should work without a problem. If you had an XML DTD with these authoring
entities, the source document would be the same, just pointing to a
schema.

If these entities are being used to develop the DTD, then you need to
unravel them and make sure that a schema can support the end result. There
is probalby no way to use these directly.

..dan


> Folks, I've been doing a fair amount of research on this and it seems I
> have one problem that may keep me in the DTD world a bit longer.
>
> Our DTD has several large referenced files containing general ENTITY
> replacement text (if anyone has ever parsed the 40051 DTD with 'dtgen'
> they have encountered those files. You normally will get several 'litlen'
> errors.) This replacement text contains markup, references to other
> editable ENTITIES and the text is generic required stuff the authors
> really don't need to redo for every TM.
>
> My question is this (and I think I already know the answer BUT thought I'd
> toss it out for verification), can I call those files from a schema? My
> searches to date have said NO. 😞
>
> If I cannot call those files, then converting to a schema won't work.
>
> Many thanks.
>
>
> Lynn
>

[LynnHales]

Dan,

The files contain boilerplate text that would be used by the author to insert large blocks of text that is required and is entered verbatim.

Do if an authoring ENTITY can be use them, the question then becomes how to declare them. In the DTD, we have the ENTITIES declared pointing to the various files. I seem to be missing this in our conversion attempt.

Thanks a lot.

Lynn
---- Dan Vint <dvint@dvint.com> wrote:
> Are these entities for the construction of the DTD or for use when
> authoring? Sounds like these are for authoring purposes. If so, then it
> should work without a problem. If you had an XML DTD with these authoring
> entities, the source document would be the same, just pointing to a
> schema.
>
> If these entities are being used to develop the DTD, then you need to
> unravel them and make sure that a schema can support the end result. There
> is probalby no way to use these directly.
>
> ..dan
>
>
> > Folks, I've been doing a fair amount of research on this and it seems I
> > have one problem that may keep me in the DTD world a bit longer.
> >
> > Our DTD has several large referenced files containing general ENTITY
> > replacement text (if anyone has ever parsed the 40051 DTD with 'dtgen'
> > they have encountered those files. You normally will get several 'litlen'
> > errors.) This replacement text contains markup, references to other
> > editable ENTITIES and the text is generic required stuff the authors
> > really don't need to redo for every TM.
> >
> > My question is this (and I think I already know the answer BUT thought I'd
> > toss it out for verification), can I call those files from a schema? My
> > searches to date have said NO. 😞
> >
> > If I cannot call those files, then converting to a schema won't work.
> >
> > Many thanks.
> >
> >
> > Lynn
> >
>

[GarethOakes]

Hi Lynn,

The two primary methods of XML reuse we come across are entities or XInclude. Entities require your XML documents to use a DTD. The DTD can be an external file and/or an internal DTD subset in the document itself.

It just so happens that you can mix and match - eg. use a schema for validation, and a simple DTD for the entities. I think that is where you will be headed, based on your description below.

Alternatively you could drop the DTD altogether and use XInclude but keep in mind that would probably involve some amount of retooling in your production workflow.

// Gareth Oakes
// Chief Architect
// GPSL (www.gpslsolutions.com)

[ptc-953343]

Ah, I wasn't thinking of the reuse entities in the schema. XInclude
is probably the best way to go as mentioned below. The other thought
is to use an internal docset to pull in your entities. So your
document could look something like this:


%entityfile;
]>
<rooteleementname &quot;callschemahere&quot;=">
%referencefromentityfile;
</rootelementname>

That approach should save your current content and just require the
change to the doctype statement and the addition of the call to the
schema. Using xinclude would require converting all the entity
references in the document.

..dan

[LynnHales]

Dan,

That approach might work. The main issue being this is a public DTD. Not sure how we could get all users to use or include the proper ENTITY declarations in their DOCTYPE header.

We could provide one, but that does not mean it would be used.

Being able to call include the files in the DTD itself has been beneficial. But if schema cannot allow ENTITY declarations, then I am not sure the other features that make it more viable are worth it.

Thanks again.


Lynn
---- Dan Vint <dvint@dvint.com> wrote:
> Ah, I wasn't thinking of the reuse entities in the schema. XInclude
> is probably the best way to go as mentioned below. The other thought
> is to use an internal docset to pull in your entities. So your
> document could look something like this:
>
> >
> %entityfile;
> ]>
> <rooteleementname &quot;callschemahere&quot;=">
> %referencefromentityfile;
> </rootelementname>
>
> That approach should save your current content and just require the
> change to the doctype statement and the addition of the call to the
> schema. Using xinclude would require converting all the entity
> references in the document.
>
> ..dan
>
>
>

[ebenton]

Lynn,
I don't know if this would work or be acceptable to your users, but you could add your doctype to the File-New menu and create a template document that would always include the proper DOCTYPE header contents.
We used to do this back in the old Adept 4.3.1 days, but I don't know how it is done in current version(s). Probably the same way, whatever that is.
If all of your documents already exist with older DOCTYPE headers, then I guess the File-New template idea wouldn't help.

[ptc-953343]

I would make a single file for all the entities, so it would just be the
single reference, then they could reference which ever individual items
you then want them to use. I was trying to see if there was an easy way to
insert this when starting a document (like making a graphic entity) but
didn't see anything. The other route would be to configure the templates
to have this main common entity reference.

..dan

> Dan,
>
> That approach might work. The main issue being this is a public DTD. Not
> sure how we could get all users to use or include the proper ENTITY
> declarations in their DOCTYPE header.
>
> We could provide one, but that does not mean it would be used.
>
> Being able to call include the files in the DTD itself has been
> beneficial. But if schema cannot allow ENTITY declarations, then I am not
> sure the other features that make it more viable are worth it.
>
> Thanks again.
>
>
> Lynn
> ---- Dan Vint <dvint@dvint.com> wrote:
>> Ah, I wasn't thinking of the reuse entities in the schema. XInclude
>> is probably the best way to go as mentioned below. The other thought
>> is to use an internal docset to pull in your entities. So your
>> document could look something like this:
>>
>> >>
>> %entityfile;
>> ]>
>> <rooteleementname &quot;callschemahere&quot;=">
>> %referencefromentityfile;
>> </rootelementname>
>>
>> That approach should save your current content and just require the
>> change to the doctype statement and the addition of the call to the
>> schema. Using xinclude would require converting all the entity
>> references in the document.
>>
>> ..dan
>>
>>
>>

[LynnHales]

Dan,

Thanks, at least we were thinking along the same lines.

Lynn

---- Dan Vint <dvint@dvint.com> wrote:
> I would make a single file for all the entities, so it would just be the
> single reference, then they could reference which ever individual items
> you then want them to use. I was trying to see if there was an easy way to
> insert this when starting a document (like making a graphic entity) but
> didn't see anything. The other route would be to configure the templates
> to have this main common entity reference.
>
> ..dan
>
> > Dan,
> >
> > That approach might work. The main issue being this is a public DTD. Not
> > sure how we could get all users to use or include the proper ENTITY
> > declarations in their DOCTYPE header.
> >
> > We could provide one, but that does not mean it would be used.
> >
> > Being able to call include the files in the DTD itself has been
> > beneficial. But if schema cannot allow ENTITY declarations, then I am not
> > sure the other features that make it more viable are worth it.
> >
> > Thanks again.
> >
> >
> > Lynn
> > ---- Dan Vint <dvint@dvint.com> wrote:
> >> Ah, I wasn't thinking of the reuse entities in the schema. XInclude
> >> is probably the best way to go as mentioned below. The other thought
> >> is to use an internal docset to pull in your entities. So your
> >> document could look something like this:
> >>
> >> > >>
> >> %entityfile;
> >> ]>
> >> <rooteleementname &quot;callschemahere&quot;=">
> >> %referencefromentityfile;
> >> </rootelementname>
> >>
> >> That approach should save your current content and just require the
> >> change to the doctype statement and the addition of the call to the
> >> schema. Using xinclude would require converting all the entity
> >> references in the document.
> >>
> >> ..dan
> >>
> >>
> >>

[LynnHales]

Ed,

That would work if all the users were using Epic, but that is not the case. Everything from XMetal to Spy and Oxygen and...

Thanks.

Lynn
---- "Benton wrote:
> Lynn,
> I don't know if this would work or be acceptable to your users, but you could add your doctype to the File-New menu and create a template document that would always include the proper DOCTYPE header contents.
> We used to do this back in the old Adept 4.3.1 days, but I don't know how it is done in current version(s). Probably the same way, whatever that is.
> If all of your documents already exist with older DOCTYPE headers, then I guess the File-New template idea wouldn't help.
>

[ptc-953926]

Just adding my 2 cents worth. We've been using this approach forever. Even did the transition from DTD to schema without any problems. All of our XML documents have headers similar to this:




%textents;
]>

The actual text.ent file is resolved through the magic of catalogs. We've used this with Arbortext, XMetaL (during an evaluation), and oXygen (currently evaluating) without issues. One advantage we have is that the doctype headers are rebuilt when documents are checked back into our CCM.

Dave
Siemens

[LynnHales]

Folks,

Again, thanks so much for the input. What I think I am going to attempt to do is include a DTD subset in the schema and HOPE that all the different tools people use will recognize it without problem.

I like the addition to each document, but because this is a publicly available DTD, there is no guarantee that ENTITY declarations would be put into each file.

I'll let everyone know how this works out when I get back to it.

Thanks all.

Lynn
---- "Hintz wrote:
> Just adding my 2 cents worth. We've been using this approach forever. Even did the transition from DTD to schema without any problems. All of our XML documents have headers similar to this:
>
>
>
> >
> %textents;
> ]>
>
> The actual text.ent file is resolved through the magic of catalogs. We've used this with Arbortext, XMetaL (during an evaluation), and oXygen (currently evaluating) without issues. One advantage we have is that the doctype headers are rebuilt when documents are checked back into our CCM.
>
> Dave
> Siemens
>