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

 


Help: OASIS Mailing Lists Help | MarkMail Help

dita message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]


Subject: RE: [dita] Foreign Generalization: Should be moved to a non-normativeappendix



Can respecialization be done on the validatable, generalized content without knowledge of which system did the generalization? Or does the wording below allow different groups to generalize in different ways, allowing generalized content to be tied to the source group's implementation?

Michael Priestley, Senior Technical Staff Member (STSM)
Lead IBM DITA Architect
mpriestl@ca.ibm.com
http://dita.xml.org/blog/25


From: "Grosso, Paul" <pgrosso@ptc.com>
To: "dita" <dita@lists.oasis-open.org>
Date: 12/01/2009 05:30 PM
Subject: RE: [dita] Foreign Generalization: Should be moved to a non-normative appendix





I can live with Eliot's suggested wording.

paul

> -----Original Message-----
> From: Eliot Kimber [
mailto:ekimber@reallysi.com]
> Sent: Tuesday, 2009 December 01 14:08
> To: Michael Priestley; Gershon Joseph (gerjosep)
> Cc: dita
> Subject: Re: [dita] Foreign Generalization: Should be moved to a non-
> normative appendix
>
> On 12/1/09 8:46 AM, "Michael Priestley" <mpriestl@ca.ibm.com> wrote:
>
> > I'm a little concerned about this - adding foreign to 1.1 was a big
> deal,
> > and part of the compromise that allowed its addition was support for
> > mechanisms that allow exactly the kind of blind generalization up to
> topic
> > that all other sorts of specialization allow.
> >
> > If we need to rewrite the section to make it less file-system-
> specific,
> > that's fine. But all sections on generalization have been normative
> in the
> > past, regardless of element. If we take one piece of the
> generalization
> > mechanism and make it non-normative, then we're pretty much giving
up
> on
> > blind generalization. That's been a basic feature of the
architecture
> up
> > till now.
>
> I think it should it be sufficient to say something like:
>
> "When the result of generalization is a new document with an
associated
> DTD
> and that DTD does not provide declarations for any XML content of
> <foreign>
> elements, the generalization processor MAY move non-DITA XML content
to
> external files referenced by  <object> elements or it may enclose the
> non-DITA XML content within a CDATA marked section."
>
> That statement is, I think, sufficient to indicate that the DITA-
> defined
> generalization mechanism provides for the case and also includes both
> possible solutions in the validation-required case.
>
> Note that this isn't (or shouldn't be) an issue for XSDs as the
content
> of
> <foreign> is xs:any with a processContents of "skip", so it's only an
> issue
> for generalized documents that use DTDs.
>
> The remaining implementation details may or may not need to be spelled
> out,
> but if the intent is to make it clear that the generalization
mechanism
> provides for the case, then I think my statement does that without
> imposing
> any particular implementation details.
>
> Generalization is a bit odd in that there's really no need for the
DITA
> standard to say anything normative about the details of how
> generalization
> is done beyond the rules for managing the class, props, and base
> attributes--everything else is necessarily implementation details that
> will
> vary based on local requirements.
>
> Cheers,
>
> Eliot
>
> --
> Eliot Kimber
> Senior Solutions Architect
> "Bringing Strategy, Content, and Technology Together"
> Main: 610.631.6770
>
www.reallysi.com
>
www.rsuitecms.com
>
>
> ---------------------------------------------------------------------
> To unsubscribe from this mail list, you must leave the OASIS TC that
> generates this mail.  Follow this link to all your TCs in OASIS at:
>
https://www.oasis-open.org/apps/org/workgroup/portal/my_workgroups.php


---------------------------------------------------------------------
To unsubscribe from this mail list, you must leave the OASIS TC that
generates this mail.  Follow this link to all your TCs in OASIS at:
https://www.oasis-open.org/apps/org/workgroup/portal/my_workgroups.php





[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]