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

 


Help: OASIS Mailing Lists Help | MarkMail Help

office message

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


Subject: Re: [office] Formula subcommittee status


I said:
> > But since this is already standard practice, and recommended by the
> > official standard,
> 
> Well, OK then. I didn't know it was already so specified.
> 
> > I think we should proceed as-is.  It works.
> 
> It's just, it seems you end up in really hairy situations if you adopt 
> this as a general practice (as opposed to a really narrow one, like 
> maybe defining formulas or elements to output).
> 
> For example, how does a processor know whether "re:something" indicates 
> namespaced content, or whether it's simply content than happens to have 
> a ":" character?

I propose that they do this trivially - if it has a potential
namespace name followed by ":", it's the namespace.
You could even say "... and there is such a namespace" if that worries you.
This is a _should_ in the specification, not a _may_.

> We'll be faced with this choice (whether to use GNames or full uris) 
> probably in the metadata work, and my understanding has always been 
> that it's bad practice to use QNames in this context.
> 
> So we may end up with a situation where they're allowed in some places 
> (say formulas) and not elsewhere. Is that fine?

Fine by me.  Though I expect we'll see this kind of issue again.
This is a well-known solution to a particular problem, and
(1) nobody seems to have a better solution and (2) it's widespread practice.
I see this as an example of standards evolving to solve real-world problems,
rather than being a problem in itself.

--- David A. Wheeler


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