Rick
>> The suggestion
> that the DTD be replaced by a RNC representation was made in Cambridge
> if not covered in the Disposition of Comments.
>Yes, and we decided not to.
OK, then three WG1 members who were in Cambridge all "forgot" about the
decision not to and decided it was a nice idea.
> I guess I am a little surprised that basic things such as <ns> (which
> I remember discussing as long ago as
Barcelona?: James was there) are being raised as if there were anything
new.
At no stage have we suggested that the <ns> element be removed. We only
suggested it could usefully be renamed to make it clearer that it only
applies to the output state of the process, not to the input state as
we, the supposed experts of the committee, had been unclear about the
scope of the namespaces in the context path declaratons in your new
example.
> What WG1 stated was
> that the use of a namespace in context statements that is not declared
> to be a namespace in the schema could be misinterpreted as an error,
> and could lead to scenarios where the namespace declared for SVRL was
> preempted by its use elsewhere, and that the simple way to avoid this
> was to declare SVRL as being a namespace in the scope of the schema.
>I don't understand what "pre-empted" means here. If there is an
xmlns:svrl binding on the schema to some other namespaces, that is fine.
But it could lead to there being two roles for the svrl: namespace
within the same declaration, which worried us.
>Prefixes are meant to be immaterial, and we are not reserving the
"svrl" prefix in any way to prevent other people from using it: we are
just using it.
Personally I hate it when namespaces are reassigned within a schema as
it makes it all too easy to misinterpret things. This is what we were
trying to ensure could not happen. OK, if you object strongly to making
the language more error proof then we can simply rely on adding a note
to the annex pointing out clearly that the prefix only applies to the
output, but I personally think that a stronger form of prohibition would
be preferable.
Martin
-- DSDL members discussion list To unsubscribe, please send a message with the command "unsubscribe" to dsdl-discuss-request@dsdl.org (mailto:dsdl-discuss-request@dsdl.org?Subject=unsubscribe)Received on Mon Nov 15 11:35:51 2004
This archive was generated by hypermail 2.1.8 : Fri Dec 03 2004 - 14:00:28 UTC