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

 


Help: OASIS Mailing Lists Help | MarkMail Help

 


 

   RE: [xml-dev] External parsed general entities

[ Lists Home | Date Index | Thread Index ]

<snip/>

> > > I do *not* use such constructs for sharing information as 
> fragments between
> > > multiple XML instances; I use XSLT to extract fragments of an 
> XML document,
> > > thus keeping every external parsed general entity in a single parsing
> > > context (set of DTD declarations for entities).

Hi Ken. Thought I'd try and confirm I understood what you
meant and present Rick with a more complete example...

If I understand what you are saying, 

1. One or more pieces of markup that need to be shared is placed 
in an external entity - a "fragment" file. This grouping is
based on version control granularity.

e.g - UsingExternalGeneralEntities.xml

<?xml encoding="UTF-8"?>
<Lession id="L1">
  <Title>Using External General Entities</Title>
  <Content>.....</Content>
</Lession>
<Tutorial id="T1">
  ...
</Tutorial>
...

In Rick's terms, this might be one test.

2. One or more of these shared pieces are then included 
into a file via the XML 1.0 supplied mechanism - a 
"library" file. Obviously there would be multiple libraries
based on your classification of fragments. This
allows dependencies (ID/IDREF) between the "fragment" files,
and any validating XML parser can be used to 
check the "library" files for unresolved dependencies.

e.g. XMLIntroductaryMaterial.xml

<?xml encoding="UTF-8"?>
<!DOCTYPE document-element
[
  <!ENTITY UsingExternalGeneralEntities 
      SYSTEM "UsingExternalGeneralEntities.xml">
  ...
]>
<document-element>
  &UsingExternalGeneralEntities;
  ...
</document-element>

In Rick's terms, this might be a test library, with one
test being dependent on another via ID/IDREF linkages.

3. To build a course, you then use an XSLT stylesheet 
to pull in the bits you want - a "grouping" file. The
details of the fragment split, and any ancilliary DTD
definitions are hidden from the user of the library file,
and may change without affecting the "grouping" file.

e.g. IntroductionToXML.xsl

<?xml encoding="UTF-8"?>
<xsl:stylesheet version="1.0">

  <xsl:output doctype-system='OutputDTD.dtd'/>

  <xsl:template match="/">

  <Output>
    <xsl:copy-of select="document('XMLIntroductoryMaterial.xml')
                    //Lession[@id='L1'])"/>
    ...
  </Output>

</xsl:stylesheet>

resulting in

<?xml encoding="UTF-8"?>
<!DOCTYPE Output SYSTEM "OutputDTD.dtd">
<Output>
  <Lession id="L1">
    <Title>Using External General Entities</Title>
    <Content>.....</Content>
  </Lession>
  ...
<Output>

In Rick's terms, this might be a particular scenario of tests that
a user might want to run. Again, the results can be checked
for consistency by a validating parser, ensuring we got all the
fragments needed.

4. The grouping file can then be rendered via a second XSLT 
to whatever format is needed.




Have I got the general jist?

The neat thing is that anyone can use someone else's library, 
without having to ensure they got all the DTD dependencies
correct (provided the library and fragment files are web-accessible). 

The only downside I see is that you have to manually include
any fragment dependencies within a grouping file, though you 
do have the protection of automatic checking afterwards. Some smart
XSLT could probably automatically resolve these as well, depending
on the structure used for the fragment and the grouping files.

Regards
Michael






 

News | XML in Industry | Calendar | XML Registry
Marketplace | Resources | MyXML.org | Sponsors | Privacy Statement

Copyright 2001 XML.org. This site is hosted by OASIS