Re: [xml-dev] Long overdue update to the UBL to UN Layout Key free rende

["G. Ken Holman" <gkholman@CraneSoftwrights.com>]

I worry the "entity" term is overloaded enough as it is.

And I think the connotation has to give the 
impression of the PDF being augmented, but 
otherwise a normal PDF.  And I think for 
non-XML'ers that the phrase has to tell them the 
way it is augmented is because it contains XML.

Along the lines of:

   XML-Stuffed PDF
   XML-Loaded PDF
   XML-Embedded PDF
   XML-Augmented PDF

Then again, perhaps the "XML" part is 
inappropriate if what needs to be conveyed to the 
user is that the PDF file has been stuffed with 
the content on which the resulting PDF file was 
based.  So, using the word "source" instead one gets:

   Source-stuffed PDF
   Source-loaded PDF
   Source-embedded PDF
   Source-augmented PDF

But perhaps trying to determine such a catch 
phrase is premature unless and until it catches 
on in concept, and perhaps even in 
standardization.  If standardization can focus on 
embedding source content somewhere in the PDF 
file, and then identifying that source content as 
XML (if it isn't obvious).  Then it is a very 
generic solution and accommodates archiving 
whatever source content (perhaps even multi-part) 
embedded inside of the single PDF file.

And given my naïveté about PDF files and 
standardization, perhaps the way I did it with 
XMP field stuffing of clear text is inappropriate.

Perhaps other members of XML-Dev with PDF expertise can comment on this.

Thanks for the enthusiasm for the idea, Stephen.

. . . . . . . . . Ken

p.s. I've been delayed with my revision today as 
I await word from a vendor regarding an invocation feature

At 2011-01-31 16:12 +0000, Stephen Green wrote:
>Sounds great. A name for such a PDF?
>
>An 'entity PDF'?
>
>----
>Stephen D Green
>
>
>
>On 31 January 2011 13:48, G. Ken Holman <gkholman@cranesoftwrights.com> wrote:
> > At 2011-01-31 13:35 +0000, Stephen Green wrote:
> >>
> >> Is there a term for this kind of PDF (with it's own data inside it
> >> as XML)?
> >> If not I reckon it's worth a few ideas to find a catchy one, isn't it?
> >
> > Not that I know of.
> >
> > But ... this approach isn't standardized anywhere.  I'm using my own Crane
> > namespace for the XMP metadata RDF section that contains the XML in clear
> > text.
> >
> > Since XMP content cannot contain structured XML, only fielded XML, the XML
> > instance is reconstituted from the XDM in a single XMP field as clear text
> > and not as markup, thus requiring the second step of serializing the clear
> > text as markup.  Thankfully this is easy in XSLT.  So I use Python to
> > extract the XMP (if I'm not using Acrobat) and XSLT to create the parsed
> > content.
> >
> > And I make these tools freely available so that the process is auditable.
> >
> > I hope to publish a revision today that more accurately reflects the actual
> > input document syntax rather than the 
> reconstituted input document syntax in
> > the XMP clear text.
> >
> > I won't announce the revision here, but I have an RSS feed of releases of
> > all of our free developer resources and so revisions can be found using
> > this:
> >
> >  http://www.CraneSoftwrights.com/resources/crane-resources.rss
> >
> > Do you have ideas, Stephen, for anything catchy to call this?
> >
> > I'm hoping this will be of interest to others, but I haven't had any
> > feedback to know if the efforts were worthwhile.
> >
> > If anyone working on standardizing PDF is interested in standardizing a
> > scheme for embedding XML in a PDF file, I'll gladly change what I'm doing.
> >
> > Thanks, Stephen.
> >
> > . . . . . . . . . . . . Ken


--
Contact us for world-wide XML consulting & instructor-led training
Crane Softwrights Ltd.          http://www.CraneSoftwrights.com/x/
G. Ken Holman                 mailto:gkholman@CraneSoftwrights.com
Legal business disclaimers:  http://www.CraneSoftwrights.com/legal