Hi Elliotte,
> I object to releasing errata to change the clear meaning of a spec (not
> that that hasn't been done before).
>
> Upgrades need a new version number.
In this case I was hoping that it is sufficiently similar to the UTF-8
BOM case, in that it's really just an acknowledgment that
Michael Day wrote:
> Hi Elliotte,
>
>> Not everyone, While I like more scripts in name characters, I for one
>> don't agree that not explicitly specifying the set of UNICODE
>> characters that can be used in names is an improvement.
>
> In that case, what about releasing a series of errata to e
Hi Elliotte,
> Not everyone, While I like more scripts in name characters, I for one
> don't agree that not explicitly specifying the set of UNICODE characters
> that can be used in names is an improvement.
In that case, what about releasing a series of errata to expand the set
of UNICODE char
Michael Day wrote:
> The only part of XML 1.1 that everyone agrees is reasonable is the
> support for more scripts in name characters, and avoiding explicitly
> specifying the set of UNICODE characters that can be used in names.
Not everyone, While I like more scripts in name characters, I for
Cory Nelson wrote:
> Better Unicode support is definitely not a minor thing.
>
But that itself is not an unalloyed characteristic of XML 1.1. XML 1.1
has better Unicode support in some respects (no C1 controls allowed,
Cambodian and Ethiopic support) but has decidedly worse Unicode support
in
Hi Liam,
> Are you sure you're not thinking about XPath 1.0 and 2.0 here? The
> changes for XML 1.0/1.1 are very small in terms of code, and there
> are very few productions in the Spec grammar that are affected.
No. XPath 2.0 could easily be implemented in parallel with the existing
XPath 1.0 i
On Fri, Jun 15, 2007 at 08:49:59PM -0400, Liam R E Quin wrote:
> But there's no use us discussing it further, it sounds as if right
> now Daniel won't even accept a patch for it (even if I had the
> time to write & test one, which alas I don't)
A lot of the cost of such a change is not developpi
On Fri, 2007-06-15 at 16:29 +1000, Michael Day wrote:
[...]
> I think that the changes required to support XML 1.1 would go so deep
> into the implementation that it could actually be easier to fork libxml2
> and have two separate libraries, one for XML 1.0 and one for XML 1.1.
Are you sure you'
On 6/15/07, Daniel Veillard <[EMAIL PROTECTED]> wrote:
> On Thu, Jun 14, 2007 at 09:56:30PM -0400, Liam R E Quin wrote:
> > On Fri, 2007-06-08 at 10:19 +0200, Oliver Meyer wrote:
> > [...]
> > > So, the short answer is "No, libxml is not going to support xml version
> > > 1.1".
> >
> > I think this
On Thu, Jun 14, 2007 at 09:56:30PM -0400, Liam R E Quin wrote:
> On Fri, 2007-06-08 at 10:19 +0200, Oliver Meyer wrote:
> [...]
> > So, the short answer is "No, libxml is not going to support xml version
> > 1.1".
>
> I think this is sad. I agree that is a silliness that we could
> do without --
Hi Liam,
> The worst is requiring XML 1.0 processors to reject XML 1.1
> documents, I think that was a big mistake. But I'd still
> like to see libxml support XML 1.1.
I think that the changes required to support XML 1.1 would go so deep
into the implementation that it could actually be easier
On Fri, 2007-06-08 at 10:19 +0200, Oliver Meyer wrote:
[...]
> So, the short answer is "No, libxml is not going to support xml version
> 1.1".
I think this is sad. I agree that is a silliness that we could
do without -- it was an unhappy compromise, and at the same time lthe
literal C1 controls
Dear Daniel.
Sorry, to have offended you. That never was my intentition.
So, the short answer is "No, libxml is not going to support xml version
1.1".
Daniel Veillard wrote:
> On Wed, Jun 06, 2007 at 11:35:09AM +0200, Oliver Meyer wrote:
>> Hi everybody,
>>
>> in xml 1.1 you are allowed to have
On Thu, Jun 07, 2007 at 09:26:39AM +0200, Tim Van Holder wrote:
> Adam Dickmeiss wrote:
> > Michael Day wrote:
> >>> Our problem area has been ISO2709 which are converted to MARCXML (from
> >>> network sources beyond our control). Right now problematic chars, say
> >>> , are just thrown away. Ano
Adam Dickmeiss wrote:
> Michael Day wrote:
>>> Our problem area has been ISO2709 which are converted to MARCXML (from
>>> network sources beyond our control). Right now problematic chars, say
>>> , are just thrown away. Another option to avoid data loss would for
>>> us to make _private_ semanti
Michael Day wrote:
>> Our problem area has been ISO2709 which are converted to MARCXML (from
>> network sources beyond our control). Right now problematic chars, say
>> , are just thrown away. Another option to avoid data loss would for
>> us to make _private_ semantics .
>
> Another option if
> Our problem area has been ISO2709 which are converted to MARCXML (from
> network sources beyond our control). Right now problematic chars, say
> , are just thrown away. Another option to avoid data loss would for
> us to make _private_ semantics .
Another option if you want to tunnel what is
Daniel Veillard wrote:
> On Wed, Jun 06, 2007 at 11:35:09AM +0200, Oliver Meyer wrote:
>> Hi everybody,
>>
>> in xml 1.1 you are allowed to have e.g. as an attribute value. My
>> xmllint does not support that version.
>> Are you planning to support xml 1.1?
>>
>> Kind Regards,
>> Oliver
>>
>> foo
On Wed, Jun 06, 2007 at 11:35:09AM +0200, Oliver Meyer wrote:
> Hi everybody,
>
> in xml 1.1 you are allowed to have e.g. as an attribute value. My
> xmllint does not support that version.
> Are you planning to support xml 1.1?
>
> Kind Regards,
> Oliver
>
> foo.xml=
>
>
>
And what i
Hi everybody,
in xml 1.1 you are allowed to have e.g. as an attribute value. My
xmllint does not support that version.
Are you planning to support xml 1.1?
Kind Regards,
Oliver
foo.xml=
xmllint foo.xml:
C:\tmp>xmllint foo.xml
foo.xml:1: parser warning : Unsupported version '1.1
20 matches
Mail list logo
