From: Werner Donné (werner.donne@re.be)
Date: Fri Oct 11 2002 - 08:17:35 PDT
Hi,
Functionally it makes perfect sense to ignore unrecognised name spaces
entirely. In fact, using name spaces in this way resembles a bit the old
SGML CONCUR feature. The trend is to make XML languages "mixable",
i.e. to allow elements of other name spaces, either in specific places in the
content model, or everywhere. In any case this mixability is an explicit
part of the document definition. So in order to allow it for XSL-FO, its
specification should state this explicitly in the document definition.
In general, mixable XML languages make sense to accommodate "orthogonal"
XML languages, such as XLink, XInclude, etc. Now such mechanisms are
always redefined in each XML language that needs them. The orthogonal
languages live, of course, in their own name space.
Making an XML language mixable makes it also truly extensible. Finally
the X in XML gets some real value. Until now it was very hard to extend
an XML language without impacting it. One had to resort to either the
entity reference mechanism or to the internal subset of the document type
declaration. The former is cumbersome. The latter is dangerous, because
the basic content model can be altered. That is strange because a document
instance can declare to comply to some document definition, but not really
do it. With name spaces and mixable XML languages modularity will increase
greatly. This has many advantages, avoiding collisions in style sheets to
name just one.
Achieving total mixability is, however, not entirely trivial. It could be done
in the application, but what would be then the value of declarative XML
validation? In principle it is done with XML Schema, which has the appropriate
elements to achieve it. However, total mixability results in large schemas.
I therefore think such a schema should be automatically generated from a
non-mixable one, the latter being the "source". One could then still choose
between total extension, leaf extension, attribute extension, etc.
Regards,
Werner.
Eliot Kimber wrote:
> --- David Tolpin <dvd@renderx.com> wrote:
>
>>>I do not think that XEP should be complaining
>>
>>about
>>
>>>any non-FO or non RX attributes. At a minimum, it
>>
>>Eliot,
>>
>>good point, but the purpose of the validation pass
>>is make
>>sure that only things explicitely allowed are passed
>>to the kernel.
>
>
> I know that there's some ambiguity about what the use
> of name spaces mean, but I don't see how anything
> *outside* the FO name space should be a concern to the
> FO processor for validation purposes or otherwise--it
> should be ignoring anything not in the FO name space,
> except for any extensions it chooses to recognize (and
> it would be really nice if XEP recognized and
> implemented Antenna House's extensions (and visa
> versa), but that's another discussion).
>
> This is not just a comment for XEP but for all XML
> processors--one point of XML name spaces is that it
> allows you to reliably ignore things. [Of course, this
> is just my opinion and I'm not sure the specs are
> solid enough on this for me to point to an authority,
> but I feel pretty strongly that this is how name
> spaces should be treated as a rule.]
>
> I would be fine if the validator reported unrecognized
> stuff with an informational message (e.g., "ignoring
> attribute in unknown name space") or a warning, but I
> do not consider the use of non-FO namespaced things to
> be *an error* at any time. That is, the use or non-use
> of non-FO name spaces for attributes *cannot affect
> the validity* of the FO-spaced aspects of an FO
> document. Therefore, their use should not cause
> validation failures.
>
> Usability point: this feature caused my first attempt
> to use the product to fail in an unexpected,
> confusing, and difficult-to-workaround fashion. That's
> not a good first impression.
>
> Using the docs, I tried to set the validation to false
> (using the run.bat script) but it didn't work. Here's
> the command-line I specified:
>
> c:\XEP\run.bat -DVALIDATE=false workflow.fo
>
> And got this response:
>
> {!cannot open false: file not found}
> [input workflow-xplore.fo]
> ...
>
> I suspect this is a side effect of hinkiness in
> Window's batch processing--I've had similar problems
> with batch files I've built.
>
> More positive note: the validation feature is very
> important and I'm glad it's there--XSL Formatter's
> lack of validation has bitten me a few times. I just
> think it's being a bit over protective on this point.
>
> When I removed the axf:outline-level attributes, XEP
> was otherwise happy and produced output almost
> identical to AHXF (it failed to render some stuff but
> I'm not sure why yet--might be a font issue or user
> error, so I'm not ready to ask about it yet).
>
> Cheers,
>
> Eliot Kimber
> ISOGEN International
>
> =====
> Eliot Kimber
> Austin, TX
>
> __________________________________________________
> Do you Yahoo!?
> Faith Hill - Exclusive Performances, Videos & More
> http://faith.yahoo.com
> -------------------
> By using the Service, you expressly agree to these Terms of Service http://www.renderx.com/tos.html
>
>
-- Werner Donné -- Re BVBA Engelbeekstraat 8 B-3300 Tienen tel: (+32) 486 425803 e-mail: werner.donne@re.be ------------------- By using the Service, you expressly agree to these Terms of Service http://www.renderx.com/tos.html
This archive was generated by hypermail 2.1.5 : Wed Dec 18 2002 - 08:41:28 PST