[docbook] Re: [DBX5] Is this a DocBook document?

[Tobias Reif <tobiasreif at pinkjuice dot com>]

Norman Walsh wrote:
> Like I said, I have mixed feelings. One of the things that's different
> about DocBook (as compared to SVG, XSLT, etc.) is that it has *a lot*
> of potential "top level" elements. That means adding version to a lot
> of places.

It should only be required and valid on the root element. A good XML 
schema language should be able to say "The root element of each document 
or fragment (no matter what it's name is) must have an attribute named 
'version'", IMHO.

> The problem with xml:version is, what does it mean in mixed namespace
> environments?
>
>   <x:v5tagname y:attr="v4+ only value" z:attr="v2+ only value">

An element belonging to SVG 1.2 can only have SVG 1.2 attributes 
(including XLink attributes) AFAIK, a DBX 5.3 element can only have DBX 
5.3 attributes I would think.

Regarding inline fragments, perhaps the SVG specs help? (eg the example 
I pasted into the other post)

I guess I'll have to think some more in oprder to see the problem you 
see ...

One possible answer:
The version attribute applies to it's element ("the outer element") with 
content, minus elements that have a different version attribute, and 
minus elements and attributes that are not part of the language of the 
outer element.

Since a language can contain stuff from multiple namespaces, the problem 
may boil down to the difference between the two phenomenons "language" 
and "namespace".

Hm ...

Anyways, adding stuff to the XML namespace is such a severe change 
affecting so many XML languages and applications that it would not be 
added before a lot of discussion which would probably take some years.

A "version" attribute in DBX5+ would also be an important change, but 
would probably be feasible in a nearer future, and would be helpful already.

> Interesting. If we add version, we might want to add something for
> profile.

Only if the TC will specify profiles, I think. Attribute "version" would 
make sense, with or without attribute "profile" (and would make most 
sense in combination with a namespaced language).

> | If we want to escape reliance on DTD, we need to find new ways for
> | providing the information that we provided via DTD doctype
> | declarations. Namespace name and version attribute will also have
> | the
> | advantage of being accessible from XSLT, thus are also useful in
> | documents which do have a doctype declaration (and ns/version can
> | also
> | be used with inlined fragments).
>
> PIs would also work.
>
>  <?schema language="http://relaxng.org/ns/structure/1.0";
>           public-id="-//OASIS//??? DocBook V4.3b4//EN"
>           system-id="http://docbook.org/rng/4.3b4/docbook.rng";?>

This would work, yes. Personally I probably wouldn't use (except as 
workaround) or recommend it as a solution, for these reasons:

* PIs are less easily accessed than XML attributes.
  The tools would have to parse the string inside the PI,
  XML attributes on the other hand are parsed by an XML parser and
  provided to XSLT/DOM/etc as nice name/value pairs.

* The namespace name in the pseudo-attribute "language" in the above
  example is not used as namespace name according to the Namespaces in
  XML spec.
  XML parsers can't know to which language the elements in the document
  belong.

* FPIs are brittle, I was told; they probably meant that URIs are more
  robust when global identifiers are needed.

* The example references a specific schema.
  If it's a canonical location then it's useful, but I'd like to get rid
  of schema-specific code or references to schemas in my documents,
  they don't belong there IMHO.

* The grammar is not XML, it can't be described using XML schemas,
  and is harder to specify (EBNF?).
  I want to be able to validate my language-identifying attributes,
  using RNG for example.

I need a simple, robust, and ideally standardized way to specify the 
language of my documents, and documents I receive (especially those 
without DTD doctype declarations) should specify their language so that 
I can work with them. There's a reason why the dcouments are written in 
XML, so the language-specifying code should also be XML. IMHO :)

Thank you very much for the very constructive discussion; it's a joy and 
and honor.

Tobi

--
http://www.pinkjuice.com/



To unsubscribe from this list, send a post to docbook-unsubscribe@lists.oasis-open.org.