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

 


Help: OASIS Mailing Lists Help | MarkMail Help

office-comment message

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


Subject: RE: [office-comment] Requirement


This will show up in JIRA but I wanted to obtain clarification from you now.

For expository convenience, we show specific prefixes and assume particular
namespace bindings in the specifications and in the schemas.  Here's my
understanding of how that is to be understood in terms of what can be done
in actual documents: 

1. There is no requirement that the particular prefix be used in a document,
and any other prefix binding can be used for the desired namespace.  This is
done with the xmlns:prefix="namespaceURI" attribute on any element, and it
is in scope on that very element and all of its attributes and child
elements until over-ruled.

2. Any namespace can be set as the default namespace at any point.  There
can be only one of these at a time, but it can be set via
xmlns="namespaceURI" attribute on any element and it is in scope on that
very element and all of its child elements until over-ruled.

3. Note in (2) that the default namespace has no effect on attributes.  If
the schema defines an attribute as being bound to a namespace, the
occurrence of that attribute in an element that permits it document must
have an explicit prefix with that binding.  The shorthand techniques made
available via (1) can be applied, however.  (You will often see XML
documents with two bindings of the same namespace, one as the default and
one with a specific prefix.  This is designed to deal with the attribute
requirement and, sometimes, an attribute-value requirement [e.g., for
referring to namespaces as in RDF CURIEs and other cases where a namespace
must be identified in a value, a practice that ODF takes advantage of].)

4. Producers of ODF documents can use these techniques as economizers if
they so choose.  Hand-crafted and tool-generated documents can certainly
have such techniques used in their production.  In all cases, conforming
consumers of such ODF documents must do the right thing with regard to the
handling of namespace declarations.

Note that no new element is required for this, because the xmlns and
xmlns:prefix attributes can appear on any existing element where they are to
take effect.

Does this address your concern?  It appears that implementers can do this
already.  Is that good enough?

 - Dennis

-----Original Message-----
From: ronnie thebonnie [mailto:ronniethebonnie@gmail.com] 
Sent: Friday, February 19, 2010 10:43
To: ODFNext
Subject: [office-comment] Requirement

+NAME
Ronnie Thebonnie


+CONTACT
ronniethebonnie@gmail.com

+CATEGORY (select one or more from below)
file format


+SCOPE (select one or more from below)
general

+USE CASE
all files where name spaces are used

+DESCRIPTION
Better use of name spaces.

Going over the elements in the OpenDocument-v1.2-part1-cd04.pdf.
It was obvious a lot of elements have a name space in front of them.
This seems rather like a waste of space considering the tricks xml can do.

Why not have a name space element that can encapsulate other pieces of
content that no longer need the name space prefix for each element.
This has some advantages, smaller files is a nice one.
When copy and pasting svg, it is more efficient because it's almost pure
svg.

e.g.
<namespace: svg>
    //all sorts of svg
</namespace: svg>

<namespace: text>
    ....
    <bibiography-configuration>...
    ....
</namespace: text>

Proposal: easier namespace handling by using an element that
encapsulates other elements. To tell the application it's all in that
namespace.
If different name spaces have the same element, then the fall-back
would be to put the name space anyway.

This can enable significant savings in large documents.

-- 
This publicly archived list offers a means to provide input to the
OASIS Open Document Format for Office Applications (OpenDocument) TC.

In order to verify user consent to the Feedback License terms and
to minimize spam in the list archive, subscription is required
before posting.

Subscribe: office-comment-subscribe@lists.oasis-open.org
Unsubscribe: office-comment-unsubscribe@lists.oasis-open.org
List help: office-comment-help@lists.oasis-open.org
List archive: http://lists.oasis-open.org/archives/office-comment/
Feedback License: http://www.oasis-open.org/who/ipr/feedback_license.pdf
List Guidelines: http://www.oasis-open.org/maillists/guidelines.php
Committee: http://www.oasis-open.org/committees/tc_home.php?wg_abbrev=office



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