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: Use of SVG namespace


Michael,

I have copied Vincent Hardy with this post since I was uncertain if he 
is monitoring the office list.

The objection that I am responding to was cited in the original post but 
I have pasted its substance here for easy reference.

****
This has to do with the distinctness of attribute names, not their 
values. Please see Appendix A of the "Namespaces in XML" 
recommendation[1] (sections 2 and 3 in particular).

In the expanded name notation offered there, the name of the "real" SVG 
width attribute (for rectangles only) would be:

   <ExpAName name='width' eltype="rect" elns="http://www.w3.org/2000/svg"/>

Whereas your example above "invents" an attribute not described in the 
SVG specification with the following expanded name:

   <ExpAName name='width' ns="http://www.w3.org/2000/svg"/>

In other words, the attribute named "svg:width" isn't meaningful in SVG 
terms, and probably shouldn't have been put in the SVG namespace since 
the SVG standard does not define it.
****

What is unclear to me is the following:

Is the problem that as specified, the svg:width attribute is defined 
only in connection with SVG elements? In other words, a syntax and not 
substantive issue, or,

Is the problem that the svg:width attribute is only meaningful in 
connection with SVG elements? In other words, it should not be used 
outside of the context for which it was defined.

If it is the latter, then I am not sure your proposal (other than step 
1) really addresses that concern.

Hope you are having a great day!

Patrick


Michael Brauer wrote:
> Hi Vincent,
> 
> below is a proposal how the SVG WG and the OpenDocument TC could resolve
> the issue regarding the SVG namespace in the case that the SVG WG comes
> to the conclusion that they consider the way we are using the SVG
> namespace to be invalid. Please note that this proposal is my personal
> proposal and has neither been discussed nor agreed by the OpenDocument
> TC so far. Can you please forward this proposal to the SVG WG. Thanks.
> 
> The proposal consist of the following items:
> 
> 
> 1. The OpenDocument TC move the SVG attributes into a namespace of its
> own, for instance "urn:oasis:names:tc:opendocument:xmlns:
> svg-compatible:1.0"
> 
> 2. The SVG WG specifies a namespace that is reserved for elements and
> attributes in a global scope, i.e. namespaced elements and attributes
> that are used in the way the OpenDocument specification uses them. I
> here assume that this namespace is called
> "http://www.w3.org/2005/svg-vocabulary";, but of course it is up to the
> SVG WG to define a proper name. An option would be decide that global
> element and attribute definition would be contained in the already
> existing "http://www.w3.org/2000/svg"; namespace, but again, this is
> something that the SVG WG has to decide based on their requirements. To
> avoid delays in OpenDocument schedule, the decision about this namepace
> is required within the next few days.
> 
> 3. The SVG WG defines the elements and attributes of the
> "http://www.w3.org/2005/svg-vocabulary"; namespace not immediately, but
> in a timeframe that is considered to be appropriate by the working
> group. This full step is optional.
> 
> 4. The OpenDocument TC adds to its specification, that implementations
> that support the "urn:oasis:names:tc:opendocument:xmlns:
> svg-compatible:1.0" namespace also may/should/must support the
> "http://www.w3.org/2005/svg-vocabulary"; namespace, and further
> may/should/must process elements and attributes from the
> "http://www.w3.org/2005/svg-vocabulary"; namespace in the same way as
> elements and attribues from the "urn:oasis:names:tc:opendocument:xmlns:
> svg-compatible:1.0" namespace that have the same local name.
> 
> 5. The OpenDocument TC in future specification moves elements and
> attributes from the "urn:oasis:names:tc:opendocument:xmlns:
> svg-compatible:1.0" to the "http://www.w3.org/2005/svg-vocabulary";
> namespace, if, and only if, definitions in the
> "http://www.w3.org/2005/svg-vocabulary"; exist and are the same as in the
> OpenDocument specification.
> 
> By using this process, the SVG WG can extend its specification without
> having to care about OpenDocument in any way, and the OpenDocument
> specification can take over the definitions from SVG without getting
> incompatible. Of course, the fact that our two groups can work
> independent of each other, does not mean that a collaboration between
> our two working groups isn't reasonable.
> 
> 
> Best regards
> 
> Michael
> 
> 
> To unsubscribe from this mailing list (and be removed from the roster of the OASIS TC), go to http://www.oasis-open.org/apps/org/workgroup/office/members/leave_workgroup.php.
> 
> 


-- 
Patrick Durusau
Director of Research and Development
Society of Biblical Literature
Patrick.Durusau@sbl-site.org
Chair, V1 - Text Processing: Office and Publishing Systems Interface
Co-Editor, ISO 13250, Topic Maps -- Reference Model

Topic Maps: Human, not artificial, intelligence at work!




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