LISTSERV mailing list manager LISTSERV 15.5

Help for XML-L Archives


XML-L Archives

XML-L Archives


View:

Next Message | Previous Message
Next in Topic | Previous in Topic
Next by Same Author | Previous by Same Author
Chronologically | Most Recent First
Proportional Font | Monospaced Font

Options:

Join or Leave XML-L
Reply | Post New Message
Search Archives


Subject: Re: Entities Declaration
From: Peter Flynn <[log in to unmask]>
Reply-To:[log in to unmask]
Date:Mon, 2 Jul 2001 15:35:13 +0100
Content-Type:text/plain
Parts/Attachments:
Parts/Attachments

text/plain (74 lines)


At Monday, 2 July 2001, Peter R Elliott <[log in to unmask]> wrote:

>Hi
>Sorry for butting in here with a possibly stupid question, but Peter
could
>you expand on this a bit? It sailed right over my head. What does
effectivities
>mean in this context?

[This is off the top of my head, I don't have time right now to dig out
a real-life example, because most of the ones I have are covered by
non-disclosure agreements and would need substantial editing before
I could post them here.]

Sorry, I should have explained. Effectivities in its commonest usage
refers to the indication (usually in an attribute) of which of your
applications the current element applies to, or what dates they are
effective between, or other external considerations. A crude example:

<para for="Ford">Remove the air filter before commencing work
on the alternator.</para>
<para for="Fiat">The alternator retaining bolts are all left-hand
threads.</para>

Often, one element will refer to several products. XML has attribute
types IDREFS and ENTITIES which can be multi-valued, separated
by spaces, eg

<!ATTLIST section models IDREFS #REQUIRED>
..
<section models="ABC123 DEF456 GHI789">
  <para>blah</para>
</section>

ABC123 etc must therefore be ID values somewhere else in the
current document. This is sometimes not convenient if the object
pointed at is not normally expected to be present in the document
(such as an entire other document) or an external entity like an
image). In this case you can declare the external entity with a
Notation (to make it unparsed, and therefore referenceable but
possibly not includable), and then refer to it in an ENTITIES
attribute:

<!NOTATION PDF PUBLIC
    "-//Adobe//NOTATION Portable Document Format//EN"
    "http://www.adobe.com/pdf/somespec.doc">
<!ENTITY datasheet SYSTEM "datasheet.pdf" NDATA PDF>
..
<!ATTLIST ref id ID #REQUIRED doc ENTITIES #REQUIRED targets IDREFS
#REQUIRED>
<!ATTLIST para id ID #IMPLIED refs IDREFS #IMPLIED>
..
<reflist>
  <ref id="xyz123" doc="datasheet" targets="foo"/>
</reflist>
..
<para refs="xyz123" id="foo">See the full data sheet for details
of the winding spool tolerances.</para>

A parser can dereference the entity but not do anything more
than check that the file exists, but if you delete either the ref or
the para, the parser will complain. You could tighten up on this
in life-critical systems like aircraft maintenance or medical
equipment documentation by making IDs required on all paras,
and adding some macro smarts to your editor to enforce their
use.

Most of this is heavy-duty industrial-strength stuff. You don't
see it, you just fly in them :-)  It's what helps to make sure that
when they put back together the engine they disassembled on
the tarmac at the airport, they're not left with two 35mm nuts
and a 3mm O-ring lying on the ground :-)

///Peter

Back to: Top of Message | Previous Page | Main XML-L Page

Permalink



LISTSERV.HEANET.IE

CataList Email List Search Powered by the LISTSERV Email List Manager