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

 


Help: OASIS Mailing Lists Help | MarkMail Help

docbook-apps message

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


Subject: DOCBOOK-APPS: Re: conditionalization of XML


-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

/ Bob Stayton <bobs@caldera.com> was heard to say:
|> 3. OTOH, I really do want this to happen before validation. That way I can write
|> 
|>    <chapter>
|>      <title condition="print">Print Title</title>
|>      <title condition="online">Online Title</title>
|> 
|>    and have the right thing happen.
|
| On the third hand, you can't load such documents into
| a validating editor.  You'd have to wait until you process
| it with conditions resolved to find out if it is valid.  Or
| you write a smart validating editor that understands your
| conditional syntax, and lets you set the conditions that
| apply for a given session.  Text outside the conditions
| could be dimmed and excluded from validation.  Now *that*
| is the way to write conditional documents.

That would be nice indeed.

| What happened to the old method of using <phrase>:
|     <chapter>
|       <title><phrase condition="print">Print Title</phrase>
|              <phrase condition="online">Online Title</phrase></title>
|
| which can be validated?

Nothing. I still think that's a good idea. And really, the most common
things I've found to conditionalize are paragraphs and phrases so I
don't think the title case happens much more frequently than the
if/then/else case.

I was just thinking about the problem more generally. The requirement
seem to boil down to:

   Accept WF (possibly valid) XML, perform profiling, produce a result
   that contains enough information to be validated, if necessary.

|> 4. That means that losing the <!DOCTYPE declaration is unfortunate.
|>    But that could be fixed, I think, with a specialty XML parser.
|
| I'm not clear what this means.

If you use XSLT, you lose the <!DOCTYPE and internal subset. That
means that you can't do down-stream validation because the information
that you need to do it has been lost.

|> 5. You know, I really want this at the URI level.
|> 
|>    <!DOCTYPE book PUBLIC "..." "...">
|>    <book>
|>      ...
|>      <xi:include href="http://localhost/profile/path/to/document.xml?condition='html'"/>
|>    </book>
|> 
|> Now we're getting somewhere!
|
| Would that be part of XPointer or XInclude?

I'm not sure. I'm thinking it's part of the URI.

                                        Be seeing you,
                                          norm

- -- 
Norman Walsh <ndw@nwalsh.com>      | When the situation is desperate,
http://www.oasis-open.org/docbook/ | it is too late to be serious. Be
Chair, DocBook Technical Committee | playful.--Edward Abbey
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.0.6 (GNU/Linux)
Comment: Processed by Mailcrypt 3.5.7 <http://mailcrypt.sourceforge.net/>

iD8DBQE9pz+fOyltUcwYWjsRAufxAJ4ktGaE7PddPtlOVKtvbrB0c2e7/ACgi246
DlOGA0BUgM4s/1VuquOl2UY=
=nBmn
-----END PGP SIGNATURE-----


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


Powered by eList eXpress LLC