[
Lists Home |
Date Index |
Thread Index
]
for an uninvolved bystander, who observes that one of the genx goals is to
"Generate[] namespace prefixes so you don't have to," the following questions arise:
Tim Bray wrote:
>
> OK, I got C14n wrong (ERH has given me a test suite so it won't happen
> again). Here's how I'm thinking I'm going to change Genx to do the
> right thing.
>
> Among my c14n mistakes was the belief that you can't have default
> namespaces in C14nized XML.
>
> 1. The existing modes work. You declare namespaces whenever you want,
> Genx will make sure they're in effect if you emit an element or
> attribute that's in a namespace.
>
> 2. You can now say
> genxDeclareNamespace(w, "http://example.com";, "", &status)
> to make this the default namespace whenever it's in effect.
> IF there is a default namespace in effect and you try to insert an
> element/attribute that's not in a namespace, that's an error.
why is the consequence not to automatically undeclare and emit a undeclaration
of the default namespace? (with the possible consequence, that the default
declaration subsequently reappears in child elements as required?)
what is the possible effect on attribute names which are "not in any namespace"?
>
> 3. There's a new call genxAddNamespace(genxWriter w, genxNamespace ns)
> that you can mix up with genxAddAttribute calls immediately following a
> genxStartElement call. The idea is that if you want to control the
> placement of NS declarations, you can. Normally, you'd do this if you
> knew you were going to have qnames in content and needed to be sure the
> prefixes were declared.
>
> 4. There's a new call genxAddAllNamespaces(genxWriter w) which makes
> sure all the namespaces you've declared so far are in scope. Normally,
> you'd do this on the root element.
why is this necessary? given the namespace scoping rules, it is not guaranteed
to be sufficient. is it just a matter of convenience?
>
> 5. There's a new call genxAddQName(genxWriter w, genxNamespace ns, utf8
> value) which will emit a QName with the appropriate prefix if you
> (gack, gag) wanted a QName in Element Content.
so long as it is not possible to declare qname content types, and so long as
the web architecture permits qnames in content, a standard serialization
interface must either include an operation of this form or an operation which
returns the correct prefix for a given namespace in the current lexical
context. one may argue that the finding on qnames in context should be
proscriptive, but, at present, it is not. given the latitude which the present
version permits, the prefix retrieval interface is to be preferred.
>
> 6. There's a new call
> genxAddAttributeWithQName(genxWriter w, genxAttribute a, genxNamespace
> ns, utf8 value)
> where the ns prefix and "value" arg are put together to make qname
> attribute value.
is this sufficient for encoding actual qnames in attribute character data? is
it not necessary to instead provide a means to determine the current prefix
for a given namespace in order to serialize things like xpath expressions?
[see above.]
>
> Anyone have a better idea?
? why is the GENX_DUPLICATE_PREFIX error necessary? if genx is already capable
of egnerating prefixes where they are not declared, why does that not apply to duplicates?
? i presume that the writers have indefinite extent. that is, that they can be
reused. i was not able to confirm this from a cursory examination of the
ongoing documentation. if this is true, the documentation needs to adress the
extent of the declarations. that is, if one were combining documents used
genxDeclareNamespace to asserted a prefix-namespace binding within the scope
of a particular element, and later, outside of the lexical scope of that
element, intended to integrate another document which presumed that the same
prefix is bound to a different namespace, would one need to contend with
duplicate prefix errors and/or prefix renaming, or do the prefix bindings have
dynamic extent?
? with respect to, for example, item 4, would it not be better to have one
mode which simply does canonical serialization and another mode in which the
application invokes the add operations explicitly?
...
|
